On Thu, 2010-07-29 at 22:02:00 +1000, Russell Coker wrote: > On Thu, 29 Jul 2010, Guillem Jover <guil...@debian.org> wrote: > > as they cannot be hardlinked it needs to create a new <pathname.dpkg-tmp> > > symlink with the same contents as the <pathname> one. But as this one is > > a newly created object it needs the permissions and SE Linux labels > > applied to it, otherwise if we need to roll-back with rename(2) from > > <pathname.dpkg-tmp> to <pathname> it would not have the correct metadata. > > But why does that require a second context lookup? Why not cache the > result of the first lookup? It's generally not going to change between > calls - while it can change you have to keep in mind that any change to > the policy is a heavy-weight operation that takes moderate amounts of > system resources (you don't do it often) and if using the context that > was used for the object a few seconds ago causes security problems then > we have bigger problems than a dpkg race-condition.
The reason for the current code is not due to fears of possible security issues from race conditions or similar, it's mainly because it makes the code simpler. If it has to cache the context lookup, we have to keep state, and free it on the intermixed return point. It's of course doable, but if the lookup is not that slow, and remember it's only performed on symlinks being replaced by something else, then I'd rather keep the current code. I've added an entry in my TODO list to possibly take a look into this in the future though. BTW, shouldn't the lsetfilecon() call ohshite() in case of error, probably excluding ENOTSUP? regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
