Albert White wrote: > Hi, > > Allowing a non root user the ability to install packages in their own > environment is a good thing. However I do have some comments. > > The patch utilities are already complex. They have evolved into this > state over the years. I remember the pain after the changes to the patch > utilities went in to support zones, lots of other things broke > initially. Perhaps a redesign of the patch utilities and packaging > database (contents file and /var/sadm/pkg) should be looked at with this > proposal as a feature of the new changes. There appears to be some > similarity with whats proposed here and how zones packaging should work. >
That is being considered as I type, but not as part of this project. > What would be the scope of this project in relation to other patching > and packaging scenarios? For example will a user in a local zone be able > to apply packages? A user on a diskless client? > Yes in a local zone (assuming the user as write privs somewhere within that zone). Same goes for diskless client. Ordinary users cannot interfere with the operation of zones or diskless clients. This proposal does not change that. > > Each domain has a sparse package registry of only those packages > > installed on that domain. The registry shares the format of the > > contents(4) file and by default is installed into ~/.sunw, but is > > overrideable with a CLI switch. > > > > Each domain has a sparse package registry of only those packages > > installed on that domain. The registry shares the format of the > > contents(4) file and by default is installed into ~/.sunw, but is > > overrideable with a CLI switch. > > > > Inter-domain dependencies are resolved by following a per-user > > Domain-Path variable (environment variable, or CLI override). The first > > domain able to satisfy the dependency is used. > > > > The "root" domain (the one that exists today on each Solaris OS > > instance) is always part of everyone's Domain-Path and is used to > > satisfy package dependencies when no other domain can. > > How does this work for the root domain? For example a user could install > say a webserver in their home domain. If a security patch was released > the administrator may want to be able to patch all webservers that are > installed, and not have to resort to sending emails to $USER. Therefore > it needs to know what domains are where. Then there are the cases of > what about an admin who needs to patch a package in a user domain in a > local zone. This is definitely an issue, however if you delegate admin for install purposes, you delegate admin for maintenance purposes TOO. And trying to maintain what amounts to referential integrity across admin domains is simply too hard. The entire web gets by without it, note. Also, keeping root from poking around into application/user data isn't a bad thing, and is done today using encrypted filesystems and secure NFS solutions. I just don't see the benefit outweighing the cost, especially since there are ways (with Sun software as well as others) to register and track installed software for the purposes of auditing and patching for security fixes, etc (for example, Sun Update Connection "knows" about your installed domains since you must register them to receive updates). > This is also relevant from a dependency point of view. The user > installed webserver could have a dependency on a system library. If the > root user was to remove the package with he library they should be > notified that there is a user domain which requires it. Another case > would be where a users requirement is met by another user domain, if the > owner of the requirement was to remove their package they should be > notified of the impact to other users. > See my prior post on DOS attacks. > > - Reduce or eliminate need to rely on root privileges and root-owned > > artifacts, thereby meeting higher security and responsibility > > partitioning standards. > > At the moment a user can be given the "Software Installation" role that > addresses the main points of 1249015 and 1165888, for they system > package database anyway. Allowing a user to add a package to a directory > helps responsibility and partitioning. But I don't see how security is > further improved. Right now only root can install and share packages on Solaris. Allowing non-root installation and sharing of non-system software will decrease the number of root-owned objects (setuid-root files, etc) and hopefully close some of the holes that attackers have used in the past. > > - Packages might need to be re-generated to indicate ready-for-UBI. > > Products not ready for UBI must be flagged > > UBI? > User-based Install > > - Packages can specify architecture and dependencies. This becomes > > difficult to fully validate at install time, given that the domain may > > exist on a shared filesystem ($HOME). Therefore, dependency failures > > and mismatched architectures are flagged as warnings. pkgchk can always > > be used to check the architecture and dependencies at any time, so this > > is not seen as a major issue. > > It's not the validation that concerns me. It's how we are catering for > users that will use sparc and x86 machines regularly with a shared > $HOME. Some consideration should be given to how they can install the > sparc and x86 packages for an application and have them 'just work' on > whatever machine they log into. I'm sure I'm not the only one with an > x86 desktop and using a sparc sunray server! Yes, you are also not the only one with this concern. There isn't a decent solution other than draconian programmatically-enforced rules about where software can go within $HOME, or best practices that say "install arch-specific software in $HOME/bin/`uname -p` and then modify your $PATH". -jhf-
