Hi James, I have some questions/comments inline...
James H. Falkner wrote: > All, > > 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. There will > be a follow-on design review in this forum once additional details are > fleshed out and vetted through this community. > > 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. > > 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. > > - Reduce or eliminate need to rely on root privileges and > root-owned artifacts, thereby meeting higher security > and responsibility partitioning standards. > We have this today with zones. See below.... > 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. > > Basically, a software domain is a container of some sort to help fence off the user access? > Users will install packages and patches using similar interfaces > as the root user. The default install locations will be relative > to $HOME. 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. > > So, if a postinstall script requires changing something in the system that the user installing the pkg doesn't have the privs to do, what happens? Is the pkg partially installed? I would assume that having to be root as we have to today elimates this issue since the postinstall scripts should be able to run without failure, barring a missing file, or conf error or something. Is it a valid concern that the scripts associated with a pkg might not be suitable for a user to run even if installing the core pkg is? How do we ensure this is not an issue? > 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. > > 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. > So, first the users domain is searched, then the root to satisfy dependencies? So, general questions: 1. How does upgrade work with this new scheme? Perhaps the answer is just as it does today, just checking. 2. Does this affect diskless client installs? 3. How does patching work? Will users be able to patch their software domains? > Restrictions: > > - Packages might need to be re-generated to indicate > ready-for-UBI. Products not ready for UBI must be flagged > > - Users should not be able to use domains as basis of DOS > attack > > - 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. > > - Domains might not always be "up" (i.e. $HOME inaccessible) - > this mustn't cause hangs > > - 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. > Have you looked at other 'containment' mechanisms offered in Solaris to achieve what you are trying to achieve? Basically, if I understand your proposal, software domains are a containment mechanism by which you can fence off users and allow them to do stuff that normally requires privs. zones provides this containment today. So does RM projects. Both may be too heavyweight for what you think you need, but they are there and maybe would work. zones are nice because you wouldn't have to modify pkgs at all, and you could give each user a zone, and they can be root in the zone and install pkgs. This might be too heavyweight for what you are trying to achieve. thanks, sarah **** > Interface changes: > > - package/patch utilities CLI changes for software domains > - package/patch creation utilities metadata for support of > software domains. > > Related Bugs/RFEs: > > 1249015 pkgadd requires root access > 1165888 allow non-root users to install software using the > package mechanism > > > This message posted from opensolaris.org > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/install-discuss > >
