FlashFXP Forums - View Single Post

Yil · 05-14-2010, 05:49 PM

I looked up the test for chmod. It's a bit more restrictive than I just said. You must be the owner (group isn't good enough) and have write access to the parent of the item via owner, group, or other. M flagged users are immune from all access checks so they can always do anything, but VFS Admins (V flag) are only immune from read/visibility checks so they would still require +w to the parent of the item, but are immune from the owner test. Of course VFS Admins could always change the permission of the parent(s) to grant themselves +w provided the entire directory tree isn't read-only all the way up to root.

This prevents everyone but Masters from deleting stuff in a directory marked read-only which is a safety feature. Note that if you are in a directory you can delete subdirectories that are read-only such as might happen with a zipscript. Normally you would use a Wipe script to delete stuff in read-only directories and it would confirm that you weren't doing something stupid...

But back to chmod. I can see why you might want SiteOps to be able to chmod anything they can see but normally things like that were done by VFS Admins as they are the people who can modify the filesystem. SiteOps were for everything else but generally dealt with user account management.

But I'm persuaded that there are cases where you might want to give someone the ability to chmod something they don't own without making them a VFS Admin. I'll add a .ini option to remove the owner test so SiteOps will work like VFS Admins which I think should solve your problem.

05-14-2010, 05:49 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	I looked up the test for chmod. It's a bit more restrictive than I just said. You must be the owner (group isn't good enough) and have write access to the parent of the item via owner, group, or other. M flagged users are immune from all access checks so they can always do anything, but VFS Admins (V flag) are only immune from read/visibility checks so they would still require +w to the parent of the item, but are immune from the owner test. Of course VFS Admins could always change the permission of the parent(s) to grant themselves +w provided the entire directory tree isn't read-only all the way up to root. This prevents everyone but Masters from deleting stuff in a directory marked read-only which is a safety feature. Note that if you are in a directory you can delete subdirectories that are read-only such as might happen with a zipscript. Normally you would use a Wipe script to delete stuff in read-only directories and it would confirm that you weren't doing something stupid... But back to chmod. I can see why you might want SiteOps to be able to chmod anything they can see but normally things like that were done by VFS Admins as they are the people who can modify the filesystem. SiteOps were for everything else but generally dealt with user account management. But I'm persuaded that there are cases where you might want to give someone the ability to chmod something they don't own without making them a VFS Admin. I'll add a .ini option to remove the owner test so SiteOps will work like VFS Admins which I think should solve your problem.