Assume:
drwxrwsr-x cvs cvs_group 4096 Jan 6 10:30 cvs
and it contains
drwxrwsr-x cvs cvs_group 4096 Jan 6 10:30 project
Assume that I am:
id
uid=100(bill) gid=100(software)
and that I:
newgrp cvs_group
which I am allowed since I am a member, so that now
id
uid=100(bill) gid=6(CVS-group)
I want to:
chgrp software cvs/project
but I get an error message:
chgrp: Operation not permitted (chown project)
I do have ‘rwx’ group permission on the project directory and its
parent directory.
All the halpviewer page says is that:
The chgrp utility can fail if you don’t have appropriate permissions.
Why can’t I make this change?
Steve Reid <stever@sreid.ott.qnx.com> wrote:
SR > Bill Caroselli <qtps@earthlink.net> wrote:
All the halpviewer page says is that:
The chgrp utility can fail if you don’t have appropriate permissions.
Why can’t I make this change?
SR > I think you have to be root or the owner of the file (as well as being a
SR > member of the group). I’ll check and fix up the docs.
Of course that’s what I assumed too. But I don’t think it is correct.
I think if I have write permission to the parent directory I should
have permission to change the owner, group, mods, etc of anything in
that directory.
Note that I CAN remove the directory as a non-owner but group member.
I would think that a chgrp is much less destructive than a delete.
Additionally, I believe that CVS requires this behaviour to enforce its
security properly.
Can someoen check the POSIX specs?
Bill Caroselli <qtps@earthlink.net> wrote:
All the halpviewer page says is that:
The chgrp utility can fail if you don’t have appropriate permissions.
Why can’t I make this change?
I think you have to be root or the owner of the file (as well as being a
member of the group). I’ll check and fix up the docs.
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
Bill Caroselli <qtps@earthlink.net> wrote:
Steve Reid <> stever@sreid.ott.qnx.com> > wrote:
SR > Bill Caroselli <> qtps@earthlink.net> > wrote:
All the halpviewer page says is that:
The chgrp utility can fail if you don’t have appropriate permissions.
SR > I think you have to be root or the owner of the file
That is correct. Owner or root (what POSIX refers to as implementation-
defined “appropriate privileges” 
There is also the concept of
CHOWN_RESTRICTED, which affects this too, and fs-qnx4 sets that attribute
(assuming you are hosted on a disk filesystem, it will be different for
each underlying filesystem manager) which further limits this.
I think if I have write permission to the parent directory I should
have permission to change the owner, group, mods, etc of anything in
that directory.
The POSIX standard disagrees with you :-/
And, in their Rationale (B.5.6.5) they say: “System V allows a user to
give away files; that is, the owner of a file may change its user ID
to anything. This is a serious problem for implemenations that are
intended to meet government security regulations.”.
Note that I CAN remove the directory as a non-owner but group member.
I would think that a chgrp is much less destructive than a delete.
POSIX only requires write permission on the parent dir to do this (so
owner/group IDs are irrelevant). We do support the UNIX “sticky”
bit on a directory, which also requires file ownership to unlink
(eg “chmod +t /tmp” in a shared environment is useful).
Can someoen check the POSIX specs?
Looks like we conform to me. The spec starts “Only processes with
an effective user ID equal to the user ID of the file or with
appropriate privileges may change the ownership …” and just gets
more strict (via _POSIX_CHOWN_RESTRICTED) from there 
The disk
filesystems set that attribute, so are the strict end of the standard.
John Garvey <jgarvey@qnx.com> wrote:
JG > Bill Caroselli <qtps@earthlink.net> wrote:
Steve Reid <> stever@sreid.ott.qnx.com> > wrote:
SR > Bill Caroselli <> qtps@earthlink.net> > wrote:
All the halpviewer page says is that:
The chgrp utility can fail if you don’t have appropriate permissions.
SR > I think you have to be root or the owner of the file
JG > The POSIX standard disagrees with you :-/
JG > And, in their Rationale (B.5.6.5) they say: “System V allows a user to
JG > give away files; that is, the owner of a file may change its user ID
JG > to anything. This is a serious problem for implemenations that are
JG > intended to meet government security regulations.”.
Yes, I discovered this rationale last night, damn it.
Note that I CAN remove the directory as a non-owner but group member.
I would think that a chgrp is much less destructive than a delete.
JG > POSIX only requires write permission on the parent dir to do this (so
JG > owner/group IDs are irrelevant). We do support the UNIX “sticky”
JG > bit on a directory, which also requires file ownership to unlink
JG > (eg “chmod +t /tmp” in a shared environment is useful).
Can someoen check the POSIX specs?
JG > Looks like we conform to me. The spec starts “Only processes with
JG > an effective user ID equal to the user ID of the file or with
JG > appropriate privileges may change the ownership …” and just gets
JG > more strict (via _POSIX_CHOWN_RESTRICTED) from there The disk
JG > filesystems set that attribute, so are the strict end of the standard.
Well, I don’t agree with it, but I can’t argue with the specs. You
are in complience.