[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: permissions - is this the best approach?



Almut Behrens wrote:
As to the permissions, setting the appropriate umask would be an
important prerequisite.  However, it doesn't _enforce_ that files in
fact do end up with the required permissions (it's only a mask after
all).  IOW, if someone copies a file that's not world- or group-
readable, it'll keep those insufficient permissions - they won't
automagically be corrected... (upon rethinking, maybe that's what
Johannes was referring to?)  Unfortunately, there's no such thing as
a "set-permission bit" analogous to the set-GID bit on directories.

Yes, this is what I was referring to. I got tired of telling people with access problems to go to the owner of the file and tell them to chmod their files (and occasionaly forgot it on some of my own files...)

So, depending on how failsafe the whole thing is supposed to become,
some special care might need to be taken.  Experience from real-world
scenarios, with real-world people (like you and me :) shows that
it's not a good idea to require them to always do something like
"chmod -R g+rX ..." after having copied stuff into the public folder.
This _will_ be forgotten, sooner or later...
One possible workaround would be to use some kind of wrapper script to
"upload" files (and ensure correct permissions), or something like that.

The solution I chose was this:
- export and mount the 'public' folder enforcing a special user and group.

If the directory is mounted from a client machine the squash_all option ensures that the mounted directory belongs to a special user (lanshare in OP's case) and group. In our case this is the desired behaviour (ie. also non-owners can delete a file), but I think it could adapted.

(Drawback: It only works on clients, not on the machine with the directory itself. I'm not sure, how to implement this. )

Looking at the manuals, I saw that /etc/exports applies to nfs; I don't know if and how such a solution would work on zeroconf (netatalk).

The solution via a special upload skript to change the permissions sounds about as complicated as the manually chown approach -- having users who are used to drag or copy/paste files accross with a file manager.

Another solution could be to run a cron job to regularly chmod -R g+rX the directory.

Johannes



Reply to: