On Wed, Apr 21, 2010 at 8:37 PM, Jorgen Lundman <lund...@lundman.net> wrote:
[snip] > Now, I might be wrong, but this what I think if the problem with Zones: > > I can not simply spin up a Zone _when the SSH login happens_, ie, dynamically > as the user connects. > This means I have to pre-create zones. Creating 30,000 zones, because I will > not know how will use it, > clearly means I need 30 servers in the SSH cluster (if I can get 1,000 idle > zones on a supermicro! Thats > 22,000 LWPs! according to someones post). That is correct. There is no way to do that within the zone framework (you have to have the zone up so that sshd can be running to accept a connection), though there might be a way to do it with some serious custom code and some sort of load balancer in front. [snip] >> Create zfs datasets for each user and put inheritable ACLs on them to only >> allow the file owner to access/see them. > > I did extensive tests with the idea of each user having own ZFS dataset. It > is just not practical. Even with automount > and mirror-mount it is not practical. I was thinking more along the lines of a dataset for each customer that is shared across all of their common accounts. [snip] >> Then, change the privilege set to only allow them to view their own >> processes. Glenn Brunette posted a good write up > > This, also mentioned by Rob McMahon is most excellent. It takes care of the > process issues completely. It only leaves > the disk access as a problem. Inheritable ACLs set on the dataset or home directory level would handle this. If all of a customer's data was in their home directory, and the home directory is setuid/setgid with ACLs that prevent other users from getting in there, and /export/home has ACLs that allows users to execute, but not read the directory, then no user will be able to see another's files, or even if they have a home directory (barring their ability to look in /etc/passwd, /etc/group and the like). fpsm _______________________________________________ sysadmin-discuss mailing list sysadmin-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
