The POSIX spec for the chown
utility mentions in its rationale section about the chown user:group
syntax (formerly chown user.group
) (emphasis mine):
The 4.3 BSD method of specifying both owner and group was included in this volume of POSIX.1-2008 because:
- There are cases where the desired end condition could not be achieved using the chgrp and chown (that only changed the user ID) utilities. (If the current owner is not a member of the desired group and the desired owner is not a member of the current group, the chown() function could fail unless both owner and group are changed at the same time.)
I thought the user:group
syntax was a convenience thing. Now the above implies there are things you can do with chown user:group
that you can't with chgrp group; chown user
Now that text doesn't make sense to me. In 4.3BSD, only root could change the owner a file so in any case there's no restriction in what he can do.
SysV and a few other systems allow (or used to allow) the owner of a file to change the user and group of a file to anything, but even in those system, that text above doesn't make sense to me. OK, if one does do a chown someone-else the-file
, one cannot do chgrp something-else the-file
afterwards because one is no longer the owner of the file, but there's nothing preventing him/her from doing the chgrp
first (staying the owner of the file) and chown
after, and that's not what the text above is exactly saying.
I don't understand what the and the desired owner is not a member of the current group has to do with the problem.
So what are the conditions for which the chown() function could fail unless both owner and group are changed at the same time, and on what system?
Best Answer
The Microsoft Interix Unix subsystem (now retired) for its NT kernel dealt a little differently with user and group permissions than some others do:
Here are some more specific manual excerpts:
As I read it that means that if your user account belongs to a Windows group with sufficient privileges to modify a file's permissions that is owned by that group, then it is possible to effectively
chgrp
that file outside your user account's control. This amounts to lesser control than you might have withchown
and explicituser:group
parameters. In that context without the possibility of declaringuser:
and:group
you never could achieve the same results as otherwise.Here is a link to a detailed look at how Interix interacts with Windows ACLs with a focus on how such knowledge might apply to Samba file-systems on other Unix variants.
Here is a link to a now obsolete Solaris document describing the tunable
rstchown
which...Apparently, if the parameter is set to a value of
0
...Such an option does not invalidate Solaris's POSIX conformance. Just that it is an option at all qualifies it as conformant:
The
chown()
system function - which is the documented system call made by both thechown
andchgrp
shell utilities - is specified to fail for numerous reasons. Among them:The behavior of granting permissions modification rights to non-root users has never been unique to Solaris, however. There is very excellent - if somewhat dated - coverage of Unix file permissions in this forum post in which the author states:
Another good - and more recent - mailing-list post quotes this and continues:
And as you point out in 2003:
...which depended upon a configuration
setprivgroup
parameter.In any case in which a non-root user can manipulate file-permissions it is conceivable, as is mentioned in the rationale quoted in your question, that a user might
chown
a file which that user owns so that it is owned by another user. If the file's group ownership and thechown
ing user's groups do not align then the user would no longer be capable of modifying that file.In this scenario
chown
thenchgrp
would fail as the user would no longer have permissions to alter that file's permissions, whereaschown user:group
- so long as group is among the user's own - would succeed.There are probably numerous other niche situations that might result similarly, which might include directory sticky and/or setgid bits, file-system and/or implementation-specific access-control lists. This thread is interesting, for instance. The countless permutations are far beyond my own feeble grasp - which is why this answer is wikied. If you're reading this, you believe it is worth improving, and you believe you know how - please do.
There is also extensive documentation on the various possible effects of file permissions, tree traversal, and symbolic links that might effect a similar failure with regards to
-R
ecursivechown
applications here:From POSIX XRAT section headings Third and Fourth Domains :
And from the POSIX
chgrp
page proper there is this which points to a possible incomplete-R
ecursive action, or at least to what used to be: