I would like typical users (of which their will be between 5-60 total) to 
login and have access to a certain sub set of folders, some users will only be 
able to read, some to read/write, but who gets to do what and where is not up 
to me; nor do I want it to be.  Instead I want some users managed by one 
delegated admin and other managed by another delegated admin.  Once logged in 
I would like the delegated admins to control users and permissions in their 
sphere and only their sphere.

However, the users should never be able to see anything outside their very 
restricted file directory.  Inside their directory they should only be able to 
do what the delegated admin says they can.

Oddly enough the last step is the most critical on.  So when a restricted user 
of the group GOLF loges in they should never see anything outside 
of /home/golf/.   After that if the admin says one user can read 
from /home/golf/courses and can read write to home/golf/clubs but still allow 
another group to only read from /clubs and read/write from /courses, if that 
makes sense.  I have no problem setting up separate groups for GOLF, COURSES, 
CLUBS, etc and setting up multiple layers such as GOLF can read everything 
in /golf but not write, and CLUBS can read and write to /golf/clubs.  But for 
now I do not remember how to do any of this… 
1)	Set up a a group with universal restrictions (read nothing but what I 
say you can)
2)	Apply the “What I say you can” permissions recursively for all 
directories and subdirectories
3)	Layer group permissions such that GOLF has read on a folder and CLUBS 
has read write on the folder and a user who is in both the GOLF and CLUB group 
can read write to said folder. 






Quoting Victor Odhner <vodhner@cox.net>:

> Hi, Bryan.
> 
> Bryan.ONeal@asu.edu wrote:
> > I want to set up a group, say Golfers, and restrict
> > them to only the golf directory, and its sub directories
> > unless otherwise stated.
> > How can I do this?
> 
> An important question is, what is it that you want them
> to be *able* to do?  Then you can give them just that.
> But as soon as they have access to fully generalized
> commands, you can't be sure they can't hack it.
> 
> You could just go through all the directories in the
> system and make sure that none are owned by that group,
> and nothing is readable by "other".  But that's really a
> tall order, and you're sure to slip up somewhere.
> 
> If you totally want to restrict them, you could give them
> a login to a restricted shell, in a "chroot" environment
> that would hide the rest of the system from them.
> 
> And/or, you could designate a special program as their
> shell, allowing them only the commands they are allowed
> to use, and set up so that any abort will be sure to
> disconnect them.
> 
> There are operating system shells such as the one
> used by aztecfreenet.org that work as a BBS but give
> users a highly restricted environment.
> 
> Finally, you could just do it all as an Apache CGI
> environment without allowing shell logins.
>   
> Vic
> 
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> 
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change  you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss