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
