Hi, > I am proposing a new project to modify the Solaris packaging and patching > utilities (pkgadd, patchadd, etc) to enable them to be used by ordinary > users with no special privileges. A summary of the project is below. > I'd like some feedback from the community on this project. The technical > stuff is admittedly high-level but I think you will get the general idea.
As I see it, allowing users to use pkg*/patch* can take 3 forms: 1. Non-root users can manipulate the system packages. (Can be done today with privileges, supposedly. Didn't for me when I tried it.) 2. Non-root users can install packages in the conventional way but in a private location using the -R flag. 3. Users can set up personal software repositories in a manner that goes beyond the simplistic view in style 2. As I understand it, this proposal is aimed at style 3. There's also a fourth possibility: 4. There is a central repository into which users can install software without privileges, and the user environment mechanism knows how to pick up software from that repository. This would be more about rules for creating, distributing, and accessing such software packages rather than the installation process. > Summary: > > This project modifies the Solaris packaging and patching > utilities to allow non-root users to install and manage > packages and patches, separate from the system-level > packages, package database, and patch database. The packaging system is not renowned for being user-friendly. Not a view I personally subscribe to, but even I would regard it as requring some level of expertise. Is it wise to inflict it upon all users? What I'm really after is a mechanism to - for users, not the system - eliminate any use of software management tools at all. Users shouldn't have to install applications at all, they should just work. > Benefits: > > - Remove barrier to using native packaging on Solaris. Many > software vendors spend effort producing parallel distributions > not based on Solaris packages, or do not produce package-based > distributions at all. This requires the product group to re-invent > technology already available in the packaging tools. Is this actually a benefit? What I can't see is why an end-user would wish to use the system administration tools to maintain their own personal files. The primary use I would have for using pkgadd as myself is to be able to install a piece of software distributed as a package into a temporary location so I can repackage it in some more suitable format (such as a tar file). > - Reduce or eliminate need to rely on root privileges and > root-owned artifacts, thereby meeting higher security > and responsibility partitioning standards. > > High level Technical description: > > This proposal introduces changes into the packaging and > patching utilities to realize the concept of a "software domain", > similar to the concept of an alternate root, but with different > semantics. In what sense does it differ from an alternate root, and what benefits does this bring? > Users will install packages and patches using similar interfaces > as the root user. The default install locations will be relative > to $HOME. It isn't clear to me that using $HOME as a default necessarily makes sense. For a single-machine setup, it doesn't matter where it goes; for a multi machine setup it makes more sense to me to associate it with a system rather than a user. Besides, I really want to avoid every user installing their own copy. I would also not expect (and certainly wouldn't expect users to understand) that some files in my filespace cannot be managed using the same tools as others. > Package objects will all be owned by the invoking user. > File locking semantics will be unchanged from the root user's > usage. Scripts will be run as the invoking user. > > Each domain has a "Domain-Home", under which all softare belonging > to that domain is installed. This will by default be within $HOME > for non-root users. A normal package might install files under /usr, /opt, or wherever - how are these to be mapped under a user's home directory? > 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. So the package doesn't follow the normal filesystem hierarchy of a package. What about all the other stuff in /var/sadm - where would that go? And what if you had many software domains - where do the package files associated with them go? > 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. That's install-time dependencies, I presume. What about run-time dependencies? How do you make sure they follow the same rules? > 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. But a user may use their files on multiple machines, on which the root domain is different. > Restrictions: > > - Packages might need to be re-generated to indicate > ready-for-UBI. Products not ready for UBI must be flagged Surely it's the other way round? All packages aren't UBI ready unless explicitly indicated. > - Users should not be able to use domains as basis of DOS > attack All you're proposing is that users can unpack file archives. I don't see how making it fractionally easier allows a user to do anything they couldn't otherwise do anyway. > - Domains cannot exist within other domains. This restriction > may be lifted in future work but for now, this simplifies > logic and removes the need for recursion. I don't see where "within" is a useful term. What do you mean here? I would (if using such a system) want the requirement to create a hierarchy of domains > - Domains might not always be "up" (i.e. $HOME inaccessible) - > this mustn't cause hangs This presumes that $HOME is independent of the system. That is going to be problematic in any event, as dependencies on the root domain may be impossible to satisfy in general. But if it's personal software then $HOME being inaccessible is going to stop you logging in so not being able to run a program is secondary. > - 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. So it's fine to install an x86 package on a sparc system? (And yes, I do want to do this. Sometimes security restrictions mean you can only install software on the fileserver, and that's only of one architecture although its clients may differ.) But generally I would see turning off validation as simply giving the user too much rope. > Interface changes: > > - package/patch utilities CLI changes for software domains > - package/patch creation utilities metadata for support of > software domains. Ouch. The pkg system is complex enough as it is, and has already been pushed way beyond its original design boundaries I suspect. Making the system more complex, and making packages (and package creation) more complex, doesn't seem to be good. > Related Bugs/RFEs: > > 1249015 pkgadd requires root access > 1165888 allow non-root users to install software using the > package mechanism But these are basically addressable with RBAC or allowing any user to use the -R flag to relocate software anywhere they have write access to. It seems to me that you're proposing something way beyond that. It's tricky enough to make software work reliably in an alternate root. (So A links against B - how does it know where to find B.) I think it's going to be very difficult to get everyone producing packages to build them in an arbitrarily relocatable fashion. I'm not sure that the problem that needs solving has been adequately identified, or that changing the package tools is necessarily a good way to solve it. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
