From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: There seems to be a problem with group permissions under redhat 9.0. If a file is created and proper group write permissions are applied, users can only modify the file, and not delete it. *** The above has been confirmed by RH Support as of 04/24/2003 I have also found that using the SUID as root on programs does not work, ie; make a batch script and suid as root when run, it will not run as root? Version-Release number of selected component (if applicable): default redhat 9.0 kernel How reproducible: Always Steps to Reproduce: - Make a user name 'test' in the 'test' group. (as root) echo hello > hi chgrp test hi chmod a+rwx hi (as test) rm hi = permission denied echo bye > hi = <--- THIS WORKS! Actual Results: The file was not deleted. Expected Results: The file should be deleted. Additional info: This is set HIGH due to the fact that this is a core system function, and could corrupt flat file databases using temp files with group permissions.
deleting a file is a directory operation, so the user needs permission on the directory. setuid shellscripts don't work in linux for security reasons
I did some more testing, I have found the problem. It seems to happen only when the sticky bit is on the directory that the file is in? ie; drwxrwx--T 2 reedsjewelers bscbrar 4096 Apr 25 08:49 test cd test -rw-rwx--- 1 root bscbrar 3 Apr 25 08:49 hi rm: cannot remove `hi': Operation not permitted rm hi = permission denied. When user is IN the bscbrar group
This is expected behaviour --- the whole point of sticky directories is to restrict deletes and renames to the owner of the file (or root). "man chmod" for the full definition of the behaviour of sticky directories.