Thanks everybody for the answer (didn't notice that thing about pkg and RBAC). I see that discussion is going on different ideas - so is quite open. I'll try to say another thing (maybe stupid) - why doesn't somebody redefine the concept of $HOME ? I mean to not force a user into $HOME folder but this $HOME to be an abstraction of all the things in the OS that one can do (including access to files/folders, access domain) - and in this hypothesis $HOME needed for login could be just an attribute in the users description - called "Logon Path" or something....
Again - I apologize if this idea is far beyond the "normal" ways. regards, Adrian. --- James Falkner <james.falkner at sun.com> wrote: > Sarah, thanks for the feedback. Responses below... > > Sarah Jelinek wrote: > > >> - 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.... > > I concur with the other folks regarding zones - this > project is not > meant to replace zones, it is targeted at the > non-root user who wants > to install non-system software without requiring > administrative > intervention of any kind and without the networking > and other system-level > overhead of creating new zones. I think it is truly > complementary to > zones. > > >> 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? > > Yes, it's a container, or grouping mechanism, for > software. > > It's not really about enforcing user access, since > we already have that > today (unix accounts, permissions, roles, etc). > This is more about allowing > non-root users to re-use the software lifecycle > management features of our > packaging system and to hopefully lend some > consistency to the non-system > software (middleware, desktop apps, etc) deployed on > Solaris. > > >> 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? > > > > Yes, absolutely this is a concern. You are not > alone in wondering what > happens when a normal user pkgadd's SUNWkvm.u to > their home directory. > There are a few suggestions thus far: > > 1. Do not allow non-root users to install packages > unless the package > is specifically marked as UBI-enabled. (FYI, UBI > stands for "user-based > install"). This has the drawback that anyone who > wants their package > to be installable by ordinary users must rev their > packages to include > a new flag. Sometimes this is too resource > intensive, especially for > older packages whose original authors are long gone. > > 2. Add a new switch to the packaging/patching tools > that say "yes, I > know this package is safe for UBI". This has the > drawback that you > will have to always add this switch, and it is YOU, > not the package > author, that must determine whether a package is > indeed UBI-compliant. > > 3. Try to figure out whether scripts really need > root privs, and fail > gracefully before trying to execute them. This is a > difficult problem > given that scripts are opaque and could do anything. > > I'm open to other suggestions. > > >> 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? > > > > Yep. However, these dependencies are "soft" in that > if you change > to a different machine (say, you mount $HOME from a > windows machine), > the system packages aren't the same, and so your > dependencies may no > longer be met. > > > So, general questions: > > 1. How does upgrade work with this new scheme? > Perhaps the answer is > > just as it does today, just checking. > > No changes. Of course, upgrade is not currently > supported directly > by the packaging tools. The Solaris OS upgrade is > done through a combination > of RE scripts, metadata above the packaging tools > (such as the > .pkghistory file), and fancy class action scripts. > The packaging tools > themselves operate in either "instance=overwrite" or > "instance=unique" > mode and they have no idea that an OS upgrade is in > progress. > > > 2. Does this affect diskless client installs? > > No, this project does not change that. It is my > intention to not > affect existing root-based usage of the tools. The > diskless client > setup tools will continue to use the exact same > interfaces they > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
