On Fri, Dec 12, 2008 at 4:03 PM, Hubert Grzeskowiak <arch-general-ml@nemesis13.de> wrote:
Aaron Griffin schrieb:
On Fri, Dec 12, 2008 at 2:20 PM, Hubert Grzeskowiak <arch-general-ml@nemesis13.de> wrote:
Hubert Grzeskowiak schrieb:
Aaron Griffin schrieb:
Aaron Griffin schrieb: > On Thu, Dec 11, 2008 at 12:47 PM, Hubert Grzeskowiak > <arch-general-ml@nemesis13.de> wrote: >> hi there, >> can it be, that the some dirs written to /var/lib/pacman/local/* are not >> chmod'ed properly? sometimes i get errors because as user i don't have >> the permissions to do anything with it (it's set to drwx------). this >> only occurs on some packages (eg. the new nmap package). other dirs and >> files inside all (also the corrupted) directories seem okay (files: >> -rw-r--r--; dirs: drwxr-xr-x) >> >> i played around with umask and sudo (always used on de-/installations) >> with no result -everything was okay- so i conclude it's a per-package >> problem. > It's not, those files are not installed directly out of the package - > pacman writes them itself. > > What is root's umask? > root's and user's umask is the same: 0077 Can you try setting it to 0022 (the default, and what I have on my system) and see if the problem persists? If it does not, we then know
On Thu, Dec 11, 2008 at 2:46 PM, Hubert Grzeskowiak <arch-general-ml@nemesis13.de> wrote: the cause... Still, pacman's explicit chmod of this dir should fix this... gah.
Dan, does pacman also explicitly set its own umask anywhere?
ok. gonna change it before updating the next time
upgraded as root with umask 0022 and it's all okay.
That's so weird... so pacman's umask setting just doesn't work?
either that or it's sudo. i've only tested it with the default umask so far and without sudo. if the bug would appear there, it would be easy to say that it's pacman setting his own strange permissions.
i think, we need a few more tests for a precise statement: -sudo pacman with non-default umask -su/root pacman with non-default umask sry that i don't make it myself, but i'm currently kinda out of time unfortunately.
sudo might do some weird LD_PRELOAD magic, causing the umask() syscall to not really work right- that is my best guess. -Dan