Ben Collins <email@example.com> wrote:
> > You mean `mount --bind'? No, definitely not. `root' still needs to
> > be able to replace the files, and it is not acceptable for one vserver
> > to be able to alter another vserver's files in any way.
> Then you are asking for special casing for an off-the-wall situation.
> Removing that part of the dpkg code opens up all sorts of security
> issues, so it cannot be bypassed.
I'm just having a hard time seeing why you even care whether or not the
chmod() fails or not - you're about to unlink the file!
If chmod() returns EPERM and you are root, then you probably:
a) have the filesystem mounted read-only
b) are trying to change permissions on a file that is immutable
In both of these cases, the subsequent unlink() will also fail and no
security is lost.
I guess what I'm attacking is a basic assumption by dpkg about the nature
of the filesystem that it is running on, that it is free to alter existing
files how it sees fit - though the normal unix convention is not to alter
existing files but to rename things on top of them.
Would you accept a patch to configure this behaviour?
Sam Vilain, firstname.lastname@example.org WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13
If it doesn't have recursive function calls, real software engineers
don't program in it.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org