Yesterday a file owned by user A needed to have its file permissions changed by a user other than A (in this case A no longer works at LHO). Normally this is not permitted other than by user A or sysadmin, however the file in question resided in the shared userapps area, and so it was indirectly possible. Here is the how and why:

All directories under the /opt/rtcds/userapps/release area have permissions of 2775 (rwx for user, rws for group [set-group-id active], r-x for all) and have controls group ownership*. This means all users who belong to the controls group (which is everyone) can delete files inside these directories even though they cannot change the files permissions. So to change the permissions on a file (e.g. make it executable) the procedure is:

• copy the file to a new one (e.g. cp one.sh two.sh)
• set the correct permissions on the new file (e.g. chmod 775 two.sh)
• overwrite the original file with the new one (e.g. mv two.sh one.sh)

the file will now belong to the new user and has the correct permissions.

Note: if the Sticky Bit were to be set on the parent directory, this would be prohibited.

* Every Tuesday I run scripts to ensure this is the case for userapps and svncommon.