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. 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? > 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 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. > - 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. > - Packages might need to be re-generated to indicate ready-for-UBI. > Products not ready for UBI must be flagged UBI? > - 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! I'm looking forward to seeing more of the design details on this. Cheers, ~Albert -- Albert White - Patch System Test - Sun Ireland albert.white at sun.com http://blogs.sun.com/albertw
