% 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 don't think anyone's arguing against this part of the change (changing
the behavior of chown on set-id directories).
% 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".
The problem with this "standard UNIX practice" (for chown on set-id files)
is that set-id is used to mean "set the euid (egid) to *this* user (group)".
That is, it is used when someone wants a program to run with a specific set
of privileges, not the just the privileges of whatever the owner/group of
the file happen to be. Thus when chowned, the file has effectively suddenly
*become* a set-id file from the point-of-view of the new privileges---a
change which is likely to be undesirable (and exploitable). Clearing the
set-id status during a chmod seems to be the best way to avoid this
difficulty within the limitations of UNIX's security model.
% 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.
One could make the exact opposite argument: Since root can chmod the file
afterwards, there is no need to preserve the bits; root can always restore
them if that's what it really wants.
In any case there is a security problem: When chowning any file there is
a race condition where the owner sets the suid bit just before the chown
(so chmoding it first doesn't help) and executes the file just afterwards
(so chmoding it after doesn't, either). This means that root chowning
*any* file while the old owner is running a process exposes the new owner
to a break-in by the old. I don't see any way around this except crossing
one's fingers and hoping the old owner doesn't luck out and get the timing
right.
% 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).
This is a problem that would exist anyway, since this behavior is normal
for non-root users. And since Linux utilities are already used to the old
behavior, this bug would mostly be fixed already. (And personally, I'd
rather risk a few slightly buggy tools than a potential security exploit
in the kernel.)
Mark
-
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/