I've been a UNIX admin for a long time. Before ACLs were being put into the kernel I know a lot of Linux/Unix people were saying that ACLs were a hack to make initial planning easier, but maintenance a nightmare and if you think you need them you should rethink your file layout. Not saying I believe this but in a situation like the one Bryan is giving I don't see any way to rethink this layout in order to accomplish his goals. Anyone with Unix file server permissions guru status want to help out with something like this? thanks, -Bill On Tue, 2005-06-21 at 13:17 -0700, Joseph Sinclair wrote: > This is definitely a case of needing ACL support. Standard Linux permissions only support a single user and group for each filesystem entry. ACL's allow you to layer permissions and provide fine-grained control. A previous poster mentioned that XFS may support ACL permissions, and SELinux provides ACL support in the Kernel. > For delegation, you definitely need to use an LDAP directory of some sort, and use standard tree layout (each delegation domain is a separate OU under the corporate head OU) for the delegation realms. Place the Roles that are assigned to the ACL's in the delegation domains, and provide admin rights for the OU only (or even a sub-OU with the roles only) to the appropriate delegated admin. > > ==Joseph++ > > Bryan.ONeal@asu.edu wrote: > > 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 : > > > > > >>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 > > > --------------------------------------------------- > 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 -- Bill Warner --------------------------------------------------- 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