This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 248366 - chgrp permission denied for file owner
chgrp permission denied for file owner
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-16 10:18 EDT by Christopher Beland
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-16 18:09:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Christopher Beland 2007-07-16 10:18:12 EDT
I have a situation where an automated process running as apache needs to share a
file with another user, foo.  For security reasons, it would be preferable if
this file were not readable to other Unix users.  The obvious solution is to
have apache "chgrp foo FILENAME", but chgrp complains that permission to do this
is denied, even though the file is owned by apache and has the group set to
apache.  This does not make much sense to me.  It also seems to have security
implications, because now apache must make the file world-readable in order to
share it.

coreutils-5.97-12.5.fc6
Comment 1 Tim Waugh 2007-07-16 11:13:46 EDT
This is a kernel permission check.  Changing component and reassigning.
Comment 2 Chuck Ebbert 2007-07-16 17:17:58 EDT
apache cannot change a file's group unless apache is a member of the new group.
Comment 3 Christopher Beland 2007-07-16 17:42:01 EDT
Any particular reason for that?  As the file owner, apache can get
read/write/execute access at any time, so it seems that the only thing that
restriction does is prevent sharing access with groups of which it is not a
member. I'm not sure why that would be desirable.
Comment 4 Jarod Wilson 2007-07-16 18:09:59 EDT
Because...

1) user creates script
2) user makes script setgid
3) user changes the group on script to one w/elevated privs that they aren't a
member of
4) user runs setgid script with elevated privs they shouldn't have

BAD.

I'd suggest perhaps making your user foo a member of the apache group if it
needs r/w access to that file.
Comment 5 Christopher Beland 2007-07-16 18:30:15 EDT
Ah, that makes sense.  Thanks for the explanation.

Note You need to log in before you can comment on or make changes to this bug.