>Your case where a user either has >access or does not, oversimplifies things because it does not take into >account read/write/delete actions on the same or differing subsets of >the same directories for groups of users. I don't think I have not over simplified things in most cases there would only be one subset, and were there are differences it would be little hardship to create an extra group. >(ie, merging a user into a >group can see the games folder, can list directory contents of games, >can download from games with one that can not upload to games and can >not delete from games, can not see the games folder, can not list >directory contents of games, can not download from games, can not upload >to games or can not delete from games.) To extend your model to my >situation, I would need to create an access group for each directory and >privelege combination possible. I think this is overcomplicating things to say you need to create every possible combination, in actual fact you would only create groups for the differences and you would then be able to go straight back this is group and only this group when you wish to make a mod (Instead of having to examine every group). Ok if you have some specials that requires that some users need say write access as well as read to a directory then granted you will need an additional group. But at the moment I am having to virtualy create a new group for each user as each one is slightly different, but normally only by one directory, this means that if I alter something in my common group I have to check and change about 50 groups. This is very time comsuming and often end in some sort of error.
>This amounts to the same thing if not >worse because of the possibility to not determine what access an >individual has after being assigned to sets of groups with conflicting >access priveleges. Yes this could be a problem were you have one group with read access on a directory merging with a group with read/write access. What is needed in the display is to show the merged access privlage on any one path for the user so that it is clear what the user can or can't do
> I also do not care for the appleshare method which I >find extremely limited. I completly agree with you but its mostly a low-brainer for simple jobs.
> In my mail to you I outlined that I do hae >experience with other operating systems, some of which use much better >methods of access control.
Of course there are better I work with Novell 3-4, NT, Solaris Unix, SCO Unix, HP Unix and some other operating systems most people have never heard of (And probable wouldn't want to touch if they knew about them (-; ) And most if not all of these allow a user to be in multiple groups.
>The only thing I agree with is the need for >a better way to manipulate the access group files, and the items within >them.
Being able to drag & drop between groups etc is going to be one inprovement another would be to be able to create a group from a template. (But only when initially creating the group)
