On Tue, Apr 20, 2010 at 8:24 AM, Jorgen Lundman <lund...@lundman.net> wrote: > Solaris 10/OpenSolaris x86 > Customer data on NFSv4 from x4540s. > > Researching various ways to setup a SSH cluster for customers, for full shell > access (to compile, and crontab etc).
Use zones. > But it would be "nicer" if I could somehow restrict what the customer sees of > other customers. Ie, Privacy laws, and leaking customer information. > So not really stopping customers from seeing and using the system-files, but > rather each others' files, user-names (in 'ps', 'w', 'ls') and so on. Yes; zones provide that level of isolation. > Worse than that, sometimes there are 'admin-accounts', with a multiple > 'sub-accounts' contained within (works great with FTP for example). Both the > 'admin-account' and 'sub-accounts' have the same UID (so that quotas are > shared). Would be especially nice if a login as a sub-account could only see > its home directory, and not other sub-account's home-directories. But as it > has the same UID, I do not see this as possible. > > I guess something like FreeBSD's jail might work, but I do not know the full > extent on how resource heavy it is. Solaris do not have jails though, right? No, but we have zones. > Solaris Zones is not a realistic options, with some 200-300 customers per > server. (Solaris zones tend to handle 5-10 per server before becoming > unusable). Really? If all you're doing is shell access, the 200-300 per server seems entirely reasonable. I have systems with 30 zones running a full web stack (apache+tomcat) without any issues. The limit is not the zones; it's a standard capacity issue. I've created and used a couple of hundred zones on a machine in the past without any issues. You really want sparse-root zones (as in Solaris 10) and lots of memory, each zone takes as little as 5M of memory if you minimise carefully, plus whatever is needed for the applications. > I could use OS level 'chroot': > > Either by copying everything needed to customer's directories, not really > realistic. > > Or all system directories/files would have to be mounted inside each > customers directory. Having a union-mount per customer probably would not be > realistic in the long run. 200-300 union-mounts might not be impossible > though, but presumably if a customer were to leave a daemon, the mount would > have to stay. Can ZFS do union/loopback mounts? (Is it called union mounts, > or is that from my NetBSD days?) > > Using rbash or similar seems to not really be for this type of situation, and > indeed, it appears really easy to run a different shell (say, bash) and have > normal access. > > Currently using standard chmod, and some ACLs, I can restrict customers from > seeing any other customer files inside their home directory. But I can not > stop the same UID. > > As a random crazy thought, I wonder if a kernel-module could be designed so > that, nobody has access to a mount point (say /export), but upon login, a > process/process group, is granted access to exactly one directory-tree inside > that mountpoint (say, /export/customer/a), and released when process is > terminated. (Although, I can already see problems with daemons creating new > process groups... oh well). > > I guess I suspect there is no answer, but I thought I would check to see if > someone has come up with something clever. Yup. Zones. They do what you're describing above. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ sysadmin-discuss mailing list sysadmin-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
