lkml.org 
[lkml]   [1999]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: odd chown difference between 2.0 and 2.1pre kernels
On Tue, 12 Jan 1999, Alan Modra wrote:
> On 11 Jan 1999, Miquel van Smoorenburg wrote:
> > In article <cistron.199901110125.UAA24076@rushlight.kf8nh.apk.net>,
> > Brandon S. Allbery KF8NH <allbery@kf8nh.apk.net> wrote:
> > >
> > >GAK!!! Security flaw here, methinks. chown should unconditionally clear
> > >setuid and setgid.
> >
> > Not unconditionally. It should only happen on regular files and not
> > directories. Now 2.0.x and 2.1.x cleared the setuid/setgid bit on
> > directories too, and that got fixed. However it looks like it
> > got fixed a bit too much :/
>
> man 2 chown
>
> When the owner or group of an executable file are changed
> by a non-super-user, the S_ISUID and S_ISGID mode bits are
> cleared. POSIX does not specify whether this also should
> happen when root does the chown; the Linux behaviour
> depends on the kernel version. In case of a non-group-
> executable file (with clear S_IXGRP bit) the S_ISGID bit
> indicates mandatory locking, and is not cleared by a
> chown.
>
> So David Niemi's code is quite correct, but I must admit I like root
> changing uid to clear S_ISUID and changing gid to clear S_ISGID.
> David, what was the reason to treat root differently? Compatibility with
> SunOS 4.1.4 and 5.1.5, which behave the same as linux-2.2.0?

Right, the new behavior is intended to exactly match SunOS/Solaris and is
should be more consistent with the rest of UNIX in general. The old
behavior was highly nonstandard and made group-controlled permissions on
directories (e.g. with CVS) rather impractical (and for that matter didn't
even match its own comments or man page).

I consulted POSIX and UNIX98 as well, but they did not have anything to say
about root doing chown and chgrp, so I went for "standard UNIX practice".
I'm also skeptical there is any compelling security reason to drop setuid
when root is doing a chown/chgrp, if root can chown it root can just as
well chmod it again afterwards. Also, if root chowning causes bits in
permissions to be cleared, it can result in some utilities not preserving
permissions as expected when doing copies and restores (depending on the
order the utility does the chown and chmod in).

Paraphrasing from POSIX.1/UNIX98 by Andrew Josey of TOG:
> Unless chown() is invoked by a process with appropriate privileges,
> the set-user-ID and set-group-ID bits of a regular file will be cleared
> upon successful completion; the set-user-ID and set-group-ID bits of
> other file types may be cleared. If the process has appropriate
> privileges it is implementation defined whether the bits are cleared.
>
> The specification only defines the behavior for regular files, and
> intentionally says it "may be cleared" on other file types to allow
> implementations to use these bits in other ways for directories and
> other files. For example on many systems (at least SVR4) doing a chmod
> g+s on a directory causes files to be created in that directory to take
> on the group ownership of the directory.

Anyone care to check behavior on *BSD, Digital/Compaq UNIX, HP/UX,
UnixWare, AIX, etc.? Don't forget, directories are treated different from
files and sgid bits may be treated differently from suid bits.

--- David C Niemi ---niemi at tux.org--- Reston, Virginia, USA ---
But only the man who cares about something in itself, who loves
it and does it *con amore*, will do it in all seriousness. The
highest achievement has always been that of such men, and not of
the hacks who serve for pay. -- Arthur Schopenhauer





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.054 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site