Re: dpkg problems. Am I alone?
Mikolaj J. Habryn writes:
>
> I mildly diagree with both, but more as a matter of principle than
> for any concrete technical reasons. The decision was specifically made
> not to do the lchown -> chown thing since we want to discourage
> incorrect program behaviour. You're probably right about no program
> depending on the behaviour, but imagine this:
>
> % mkdir a
> % mkdir b
> % mkidr c
> % ln -s /etc/passwd a/b/c/.fish
> % mail root
> Hi, I have some files in my directory that I can't delete, because
> blah blah blah. Could you please do something about this?
> ^D
> %
>
> <some time passes>
>
> # chown -R user ~user
>
> Note that this remains a problem until someone recompiles chown(1)
> anyway - but don't tell anybody.
Hello Mikolaj,
I am not sure to understand, your example is argumenting towards the
adoption of my change:
- the chown program can use either the chown() function or the
lchown() function where available with -h.
- since a few weeks, and if we do nothing, a super-user executing
"# chown -R user ~user" under kernel 2.1 will change the owner fo
/etc/passwd (except if it uses the -h flag).
- With my proposed change, the principle of least surprise would be
applied, symbolic links will never be followed, whether or not the
chown program or whatever has been recompiler, and whether or not the
super-user is aware of the change that he must now use -h. (Anyway a
super-user doing the command above blindly deserve to be shot, think
about hard links).
> Secondly - kernel versions and things. Erm - as a matter of
> principle, I prefer to do feature tests than version tests. It's
> marginally more complex (one syscall either way, but slightly more
> complex parsing), and it won't handle cases where people tweak kernel
> version numbers or merge subsets of patches (admittedly, uncommon).
I also agree that feature tests are generally much better because
they still work in unexpected situation. But in the situation we are
speaking of, THE SIMPLE FEATURE TEST DOES NOT WORK IN SOME KNOWN AND
EXPECTED SITUATIONS, so I would much prefer a version test that works
in all currently known situations (even if it may fail in some exotic
case in the future, for instance somebody randomly modifying a custom
kernel with an army of monkeys in the hope to get the source code of
NT :-).
But if somebody is completely allergic to version test, I suggest we
try at least to test in the libc that we are not subject to the bug in
old kernels, that are returning EPERM instead of ENOSYS. Would that be
ok, if we decide the kernel is broken when:
- it returns EPERM
- we are root
- the kernel version is one normally known not to support lchown?
(it is important to test the kernel version because it is the
only way to distinguish from NFS root squashing behaviour, and there
may be other cases).
Regards,
Loic
Reply to: