Re: chown and security

Martin von Loewis (martin@mira.isdn.cs.tu-berlin.de)
Sun, 8 Feb 1998 22:59:55 +0100


> > That surprised me too. I would have expected that lchown()
> > would get the system call number of the old chown().
>
> I suspect this is the _right_ way to solve this. What do you think?

I don't think so. What we would get is the following:
- chown(2): in linux <2.1.80, does not follow links
in linux >2.1.90, does follow
- lchown(2):new to 2.1.8x, does not follow

- chown(3): does not follow, if:
compiled on linux <2.1.80, running on that
(e.g. libc 5, glibc 2.0, glibc 2.1)
does follow if compiled on Linux > 2.1.80 (e.g.glibc 2.1)
- lchown(3):new to glibc 2.1

- chown(1): does not follow, if
compiled and running on all-old system
or compiled on an all-new system, with -h option
does follow, if
compiled on an old system, dynamically linked with a new libc
or compiled with an all-new system

With the way it is now, chown(1) does not support -h, and magically
changes behaviour when you replace the kernel. When you then recompile
libc and chmod, it will also support -h, and keep the new behaviour.

Under your proposal, chown(1) will magically change the behaviour when
you recompile libc, depending on the kernel header files you've
installed.

It seems better to document the new behaviour of chown(2).

Regards,
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu