Re: permissions - is this the best approach?
On Thu, Jan 19, 2006 at 12:45:55PM -0500, Chinook wrote:
> Johannes Wiedersich wrote:
> >>On Thu, 2006-01-19 at 01:38 -0500, Chinook wrote:
> >>>The idea is to allow various users on the Linux box the ability to
> >>>create and delete their own files in /home/lanshare/public and to
> >>>read/copy any files therein. The Mac will create and delete files
> >>>therein as the user "lanshare."
> >
> >Dexter wrote:
> >> In principe, it`s correct. Write permission and stiky bit on folder
> >> make, that everybody can create file in this directory, but only owner
> >> of the file can delete it.
> >
> >IIRC, things may become messy, when users start to *copy* files to
> >/home/lanshare/public. Then the sticky bit is not preserved; it works
> >only for files *created* in that directory. It should be noted
> >somewhere in the info pages.
>
> I appreciate the heads-up about the "copy" issue. It would certainly
> come up and I was not aware of it.
Hope you don't mind me getting nitpicky here, but I'm not really sure
what that copy vs. create issue might be, and how it would relate to
the effect of the directory's sticky bit (i.e. everyone can create, but
only owner can delete)...
AFAIK, all that matters here is that the sticky bit is set on the
_directory_, and that the directory is writable. The files therein
don't need any special bits set. IOW, there's no need to preserve
anything. (Prominent examples are /tmp, /var/tmp and /var/lock)
Also, I wouldn't know how "copy" could get around creating the files
in the first place (at their destination). At the system call level
it all boils down to the same steps anyway, which essentially are
open (with appropriate flags set)
write
close
independently of whether cp, tar, or any other tool is being used.
But maybe I didn't quite understand what Johannes meant. Any example?
Maybe there's some confusion with the set-GID bit on directories...
which is often used in similar shared-file-access contexts, or even in
combination with the sticky bit.
Having said that, a few more comments on your original question :)
As I understand your requirements, everyone (including the user
'lanshare', representing the Mac side) is supposed to be able to read
all others' files, but only write/delete their own. The latter is being
taken care of by the sticky bit. Whether files can be read by others,
though, needs to be set up by using appropriate ownerships and/or
permissions. Here you have several options.
One would be to have all files be created world-readable.
Another would be to allow access via some common group (lanshare),
which means that files would need to be created with that group
ownership, and group-readability, of course. As you probably know,
the default group ownership is determined by the primary group of the
creator. Not sure how exactly you've set things up, but I suppose
you've made the 'lanshare' group just a supplementary group of the
users. In that case, the set-GID bit on directories might come in
handy, as it sets group ownership to the ownership of the directory
that the files are being created in (not telling you anything new, I
guess...).
A third option would be to make sure that every user is a member of
all possible groups that files happen to belong to (note however, that
under certain circumstances there's a limit to the maximum number of
groups, e.g. 16 groups with NFS v3).
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.
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.
Anyway, good luck with your Mac<->Linux connectivity.
Almut
Reply to: