Reg, A good idea.
The long story short is that this is a home system on a N40L server. Simple set up, three drives in a RaidZ. 1) There is a "guest" area where guests can transfer data to and from the server (the owner can copy data there specifically for the guest without having to give them access to the main structure) ... and as such the guests will need to be able to read and write to this area. ...the issue here is that any files that the user copies to that area will have their permissions and ownership, so there is a need for those files to then be changed so that the guest can get at them ...also there is an issue that any files moved from the guest area in to the main storage will have the guests credentials and need to be changed appropriately according to which area they have been moved to. 2) A read-write area where the main user can use the files with no issue. 3) A series of read-only folders where a different, elevated user, is logged on deliberately in order to manipulate files in the read only areas. This is so that any virus that gets on to a client, can not damage these areas as the elevated user is not in common use. Also, it helps prevent accidental deletion. ...so files which are copied by the elevated user have to also be accessible by the read-write user, and also any files that the read-write user puts out of read-write and in to read-only will also require a permissions and ownership change so that they are put out of reach of potential change. And in all this, the files can be moved/changed in the system via either SMB (which the guests and read-only users are going to use) and SFTP (which is most likely the vector that he will go in to the server for the read-write elevated user ops.) Michelle. On Wed, 20 Aug 2014 13:49:07 -0700 Reginald Beardsley via openindiana-discuss <[email protected]> wrote: > Michelle, > > I would like to suggest articulating the policy you want to > enforce. You started with a proposed solution that you were having > trouble getting to work satisfactorily. > > I had the strong impression that a simpler approach would do what you > want, but no information upon which to suggest a solution. All I > knew for certain was that it all sounded rather complicated. > > Trying to implement a policy you can't clearly state is not likely to > succeed no matter how hard you work at it. At best you get something > that seems to work until you discover it had unintended consequences > which are now causing problems. > > Reg > > _______________________________________________ > openindiana-discuss mailing list > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ openindiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
