FS#7525 - Permissions of .pacnew files

Attached to Project: Pacman
Opened by Maciej Sitarz (macieks2) - Thursday, 28 June 2007, 01:35 GMT
Last edited by Dan McGee (toofishes) - Monday, 09 July 2007, 04:32 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.5
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
After updating packages, the .pacnew files have wrong permissions set:

$ LANG="" ls -l /etc/sudoers*
-r--r----- 1 root root 723 Jun 20 02:11 /etc/sudoers
-rw-r--r-- 1 root root 608 Jun 27 00:26 /etc/sudoers.pacnew

("storylike" description here: http://bbs.archlinux.org/viewtopic.php?id=34606)

Steps to Reproduce:
1. Be sure that /etc/sudoers file is modified (not default after install)
2. Update sudo package
3. Check file permissions of sudoers.pacnew file created
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 09 July 2007, 04:32 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in git
Comment by Dan McGee (toofishes) - Thursday, 28 June 2007, 12:25 GMT
I should have just fixed this in GIT...it needs some testing. As far as I can tell, this has always been an issue with the way pacman has copied files, even prior to 3.0.X.
Comment by Xavier (shining) - Thursday, 28 June 2007, 15:32 GMT
Oh, there is a little error I missed in your patch : stat returns 0 on success.
fixed here : http://chantry.homelinux.org/~xav/git/gitweb.cgi?p=pacman.git;a=commitdiff;h=1a3b3bc1300b42dc2f554a6faa09b5ece2d3321c

seems to work fine after that change.
Comment by Xavier (shining) - Saturday, 30 June 2007, 15:03 GMT
Currently, files in backup are first extracted to /tmp/, for computing md5 or sha1, then based on that,
it determines if it should install it or not (with .pacnew suffix or not),
and then copies it from /tmp/ to final destination.
Now an additional chmod was added after the copying, to preserve the permission, and fixing the reported bug.

But I was thinking about another way of fixing this :

first compute md5 / sha1 by reading the file directly from the archive (without extracting it on disk),
then based on that, determine if the file should be extracted or not, with or without the .pacnew extension ,
and finally, extracting the file from the archive directly to the final filename.

So instead of three steps :
1) extracting to /tmp
2) copying if needed
3) chmod

we could have instead :
1) read from archive a first time, and compute md5 on the fly
2) extracts if needed on disk (a second read from the archive, so less efficient :( )

It would have avoided the current bug, and also the following bug with libarchive 1.3.1 :
http://bugs.archlinux.org/task/7323
Comment by Andrew Fyfe (space-m0nkey) - Sunday, 08 July 2007, 16:58 GMT
There's 1 big problem with this there's noway to re-read an entry from an archive, so you would need to buffer the file contents in memory (could be a problem with big files).


Dan's patch has fixed the problem. For now there doesn't seem to be a better solution.
Comment by Xavier (shining) - Sunday, 08 July 2007, 17:27 GMT
Well then, maybe we could read the whole archive a first time, for determining how to handle backup files (on the fly md5 computation),
and we record this information somehow.
And then a second time, where we actually extract the files.

Otherwise, the files in backup array are always small config files afaik, but well, it could be indeed be safer
to avoid putting the whole file in memory.

Oh well, finally, the current behavior is alright I guess, and this is probably not the correct place for discussing about things anyway (silly me).
So I think this bug could be closed now :)

Loading...