Hello,

I was thinking about the fact that a "normal" user can
add/rem packages to a system not only $HOME.
The idea mentioned here is great.
But what about linking pkg/patch tools to a PAM
module(s) ? 
Or to some special privileges ?

best regards,
Adrian.

--- "James H. Falkner" <James.Falkner at Sun.COM> 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
> _______________________________________________
> install-discuss mailing list
> install-discuss at opensolaris.org
>
http://opensolaris.org/mailman/listinfo/install-discuss
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Reply via email to