[ Note: This proposal/discussion are on install-discuss ] Thanks, James. You have seconds. I'll contact you offline to get you set up.
Eric On Tue, 30 May 2006, 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. > > 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. > > 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. > > 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. > > 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. > > 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 >
