after the sandbox code was updated solar pointed out another issue ... the /tmp/portage-prelink.tmp.portage_lockfile is created in very much the same manor in portage.py with no sanity checks unlike the sandboxpids file though, i dont see any reason for this file to be created in /tmp ... nor do i see a reason for static naming ... ive pointed out (iirc) in other bugs (or at least on irc) that parallel emerges can break because they stomp each other in a race condition over this file solution i think is to utilize some interface in python (i'm not a python mast0r) similar to tmpfile() and to build the file in somewhere that only portage/root would/should have access to it ... perhaps ${PORTAGE_TMPDIR}/lockfiles/<random name> ... i think that would solve all the aforementioned issues if the dir was say root:portage 660
I think the mode for any such subdir would be 770(-rwxrwx---) vs 660(-rw-rw----) without the ug+x on the dir I don't think we would be able to read inside of it.
Portage uses a lockfile for that file, so it won't race itself. This file is also only used for md5 checks... I suppose you could race portage for it... The end result would be not deleting files. This isn't quite the same concern as sandboxes truncation issue, but it could be an annoyance as a local user could add to system stale files. Nothing gets executed and it's a pure copy... Nothing overly insecure about it. I suppose you could defeat the md5 check and the lockfile if you really applied yourself to it, but this only applies if you support prelinking on that system... On a side note... As a user, you could probably cause portage to sit in a blocked state by acquiring an exclusive lock first. :-/
Nick, Do you think we should move the lockfile handling to ${PORTAGE_TMPDIR}/lockfiles/ as SpanKY suggested as a saftey precaution? I'v also also seeing an excessive amount of odd voodoo going on with that file.. Note I don't have any parts of prelink on my system installed or in FEATURES. I'm guessing this is not expected behavior. root# strace -o ./woof -eopen -f emerge portage user$ grep open\(\"/tmp woof | uniq 3161 open("/tmp/portage-prelink.tmp.portage_lockfile", O_WRONLY|O_CREAT|O_LARGEFILE, 0660) = 3 3161 open("/tmp/portage-prelink.tmp.portage_lockfile", O_WRONLY|O_CREAT|O_LARGEFILE, 0660) = 7 user$ grep open\(\"/tmp/portage-prelink.tmp.portage_lockfile ./woof | wc -l 119
Actually, that's expected behaviour. attempts locking for the checks iirc. Still an issue? the prelink-chksum fooling around w/ files takes place in /var/lib/portage last I looked.
Reassigning to security. dev-portage any progress on this one?
This is fixed as ferringb noted. All prelink temp files are now created in /var/lib/portage which has root:portage (2770) permissions.
This has been fixed for so long now that I would think this should just be closed without a GLSA.
Security please comment on need for GLSA on this one.
I agree with solar. If the fixed version is very old, better not issue a GLSA about this.
Two NO votes -> closing, Reopen if you wanted to vote YES
