Permission problems when using personal file sharing...

Wednesday, February 18 2004 @ 10:14 AM GMT

Contributed by: unix

We have a small "problem" when using personal sharing in our small office:
some users use their Public folder to share Word and Excel documents with co-workers (connecting to the "server" with a password, not as guest) , and this works perfectly. However, these documents don't have the write permission set by default, the "owner" has to manually give the write permission to other users. If he/she forgets to do so, other people will open the file, edit it and when saving, they will be alerted that they don't have write permissions. Then the only way to save their work is to save the document somewhere else where they have write access. Then they have to alert the owner to replace manually the old version by the latest one...
This is of course the potential source of headaches and lose of data...
Is there a way to tell a folder that everything coming in it, has to be made writable by others ?

Some shareware tools do exist (like SharePoints) but if they are useful for other aspects of file sharing especially in mixed OS9/X environments, they don't seem to change Unix permissions of shared documents.
Some may think that with folder's action and some AppleScript extension able to access the Unix file permission the trick could be done. However, two problems will rise:
1. folder actions don't spread recursively, if you put a folder in the "Public" folder, this added folder will not inherit the action script. If later you put a file in the newly added folder, the action script will not be triggered. If you make your action script to attach itself to any added folder, then be careful that if you later move this folder out of the "force write permission" hierarchy of folder, it will keep its action script attached... creating a potential security hole;
2. Action scripts are run with the logged user priorities, and this canít be sufficient to change permissions on a particular file... and it would probably unacceptable to ask for admin password each time...
The solution could be a shell script attached to the cron tasks list of the root user, that will run periodically and recursively set the desired permissions to every document and folder in the targeted hierarchy.
However, if you want different permissions for folders and documents (you may want 777 for folders and 666 for documents), you have to test each item and this prevents you to use chmod -R.
We have put here a small C program (source code) that will help you implement a solution: it's a command line tool you can easily attach to a cron task. You specify on the command line permission for folder, permission for documents, owner and group to enforce and the folder to be recursively scanned. (Permissions may have the + sign in front of them to mean "add the following permissions to the existing ones", this allows to not clear the executable bit of documents if its' already set: example: +666.)
Instructions how to compile it are in the source file.
Note that if you don't want to attach it to the cron tasks list of the root user, it will not be able to change permissions of files not owned by the current user, unless you set the setuid bit by chmod 6755 cleanpermd. We don't recommend this solution, attaching the tool to the root cron tasks list is better (unless you don't authorize the enabling of the root user in your office).

1 comments



http://www.macosxguru.net/article.php?story=20040218101443496