[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    Re: [Netatalk-admins] Permissions how-to?
From:       "Andrew Dorrell" <enviscom () pnc ! com ! au>
Date:       2002-08-25 13:46:51
[Download RAW message or body]


On Sun, 25 Aug 2002 02:42:46 +0200, Thomas Schierle <ts@visual-s.de> wrote :

> >> However, if you are running a quite recent release of Netatalk, there
> >> should be no need to adjust settings for "special" folders if you
> >> follow the below steps for setting up a new sharepoint:
> >> 
> >> -create the root folder, 2777, root, users
> >> -create a netatalk admin group, create an admin account (member of
> >>  netatalk admin group)
> >> -add the admin group option to your afpd.conf
> >> -log on to that share with admin account
> >> -copy some files to the new share
> >> -search for some files at the share using Sherlock
> >> -adjust root folder view
> >> -put all files to trash
> >> -empty trash
> >> -log out
> >> -eventually adjust group/permissions of the sharepoints root folder
> >>  according to your needs
> >> -done
> >> 

Might I suggest you separate the issues of policy from implementation.  So
for example you say

> 1) multi user sharepoints should be sgid

but if they are read only for most users is this required?


Perhaps the following:


To setup a share area that a group of users have read and write access to:

1. create (or assign) a user to own the share:

  useradd shareowner
  mkdir <path-to-share>
  chown shareowner <path-to-share>

2. Access to the share is controlled using unix group permissions so
   the second step is to create (or assign) a unix group to own the
   share and sett appropriate access permissions on the share for the
   group:

  groupadd sharegroup
  chgrp sharegroup <path-to-share>
  chmod g+rwxs <path-to-share>

All members of the sharegroup group can now read and write files in
the new directory from unix.  Note that the 's' in the permissions
means that all new files and directories created in tye share will
also be owned by the sharegroup group.  The access that users have to
each others files in the share can now be controlled via the users
umask.  In particular:

a. If a user's umask is 002 then other users of the share will have
   the same access to the files created by this user (may read, write,
   delete  etc.).

b. If a user's umask is 022 then other users of the share will
   (nominally) have read only access to files created by the user (and
   execute).


Note that sharegroup need not be the users primary group.  In general,
users can be added to as many groups as required.  For example the
command:

  usermod -G sharegroup <user>

adds user to the group called sharegroup without changing the primary
group that user belongs to.



> 2) some folders (esp. .AppleDouble, .AppleDesktop) need to be world R or
R/W
> if you decide to allow guest R or R/W access.
> 
> 3) multi user sharepoints should be owned by root (or another designated
> volume admin, who will be su for the sharepoint) because just their folder
> view "sticks". Well, and of cause you don't want to allow users to alter
> access rights for vital resources :-)


OK this is where I start to get into trouble as I don't fully
understand.  In particular I don't know exactly what goes into
.AppleDouble and .AppleDesktop and so I can't determine exactly what
the effect of permissions on these files will be for users of the
share.

In your set of steps I understand that accessing and copying some
files to the share will ensure creation of the .AppleDouble and
.AppleDesktop folders.  I guess you trash these files at the end as
you don't really want them on your share but just want to initialise
the share.  I do not understand at all the role played by 
 - using sherlock to search for some files
 - changing the folder view

One thing that troubles me is this notion that a certain users folder
view "sticks".  I have encountered before a case where the entire
contents of a directory are not visible untill the owner has accessed
the folder.  It seems to me that the permissions a user has to a file
should solely determine the access to that file.  And that read only
access should not prevent the creation of a desktop database (icons
and folder views?... even though it may require a dbpath style option
in the config file entry for the share).  As it stands a users access
to a file seems to be determined by a combination of their permissions
to access the .AppleDouble and .AppleDesktop folders and their
contents as well as the actual file.  

Am I missing something here?  

If this is true then typically I would want to create .AppleDouble and
.AppleDesktop folders with 777 permissions.  As you note this means
users (expecially on unix side) can trash important information.
Perhaps it makes sense to put .AppleDestop and .AppleDouble in a
completely independent localtion (such as /var/netatalk/*) as is
possible with the .AppleDB




> btw, home directories don't need any attention unless you/your users want
> to create drop boxes, public folders etc. Given the case you/your users
want
> to do some funky stuff inside home directories, you probably need to
> add some preconfigured folders to the home directory skeleton
/etc/skel/...
> I don't know about any more details as my interest is into multi user
shares
> only -- but creating all that special folders with appropriate mod should
> suffice (I believe you cannot control U/G, for a Suse system you'd always
> specify root/root, resulting into <username>/users)
> 


I don't want to do anything this "funky" :-)

I anticipate a problem arrising with making a folder in a users home
directory visible.  It would seem to require making the top level user
home directory available as a mount point to all users.  This is
because access to the .AppleDesktop directory for the users home share
would be required by the guest user if the "dropped" file is to have
and icon etc?  Again... am I missing something here?  It just seems
like a limitation in the way netatalk manages the mac extras.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Netatalk-admins mailing list
Netatalk-admins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-admins
[prev in list] [next in list] [prev in thread] [next in thread]