[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 07 Apr 2006 02:31:52 +0000
> Why should I not be permitted to change the group permissions on a file
> owned by another user in the group, when the group ownership of the file
> and parent directory is set to a group to which we both belong? Sorry if
> this is not a bug, it's just incomprehensible to me that using the same
> user/group/permissions and a different method I can essentially accomplish
> what chmod says is not permitted.
Because POSIX says so.
"Only a process whose effective user ID matches the user ID of the file, or
a process with the appropriate privileges, shall be permitted to change the
file mode bits of a file."
"The chmod() function shall fail if:
The effective user ID does not match the owner of the file and the process
does not have appropriate privileges."
> Consider the following:
> address@hidden test]$ ls -al
> total 12
> drwxrwxr-x 2 mike www 4096 Apr 6 12:03 .
> drwxr-x--- 11 mike www 4096 Apr 6 12:03 ..
> -rw-rw-r-- 1 sarah www 15 Apr 6 12:03 testFile
And are you currently executing as the group www, or in some
other group? When you belong to multiple groups, some systems
refuse to let you change file permissions of a file owned by
a group that does not match your effective gid.
> address@hidden test]$ chmod g+x testFile
> chmod: changing permissions of `testFile': Operation not permitted
chmod(1) is just reporting the error that the kernel reported
in chmod(2). There is nothing coreutils can do about it - changing
this would require a kernel change.
> So it's OK if I overwrite the file with a copy that has the group
> permissions set the way I want. This doesn't make sense to me. The only
> difference I can see between allowing group permissions to be set directly
> vs. indirectly is that now the file is owned by mike:www instead of
> sarah:www. So if this is the reason "Operation not permitted", why not make
> chmod able to check if current user has write permissions on file and
> parent directory, and if so, change the group permissions as requested, and
> change the owner to the current user?
As odd as your situation is, it can't be changed without breaking lots
of legacy scripts. It also highlights why sticky directories are generally
a good idea, so that another user can't overwrite your files.
- chmod, Michael_Konikoff, 2006/04/06
- Re: chmod,
Eric Blake <=
- Re: chmod, Michael_Konikoff, 2006/04/07