On Wed, 2006-05-31 at 23:38, Casper.Dik at sun.com wrote: > >As I see it, allowing users to use pkg*/patch* can take 3 forms: > > > >1. Non-root users can manipulate the system packages. (Can be done > >today with privileges, supposedly. Didn't for me when I tried it.) > > RBAC could do this but one can argue that a role which allows this > is very similar to giving full root access because pkg* and patch* > commands: > - allow installation and modification of random files at random > locations > - run scripts as root > - install set-uid binaries > > To make that all safe is rather difficult (I can imagine signed packages > being allows on in such a fashion more easily then any other package)
This is true of other RBAC roles as well; I once used Cron Management to get back into a hosed development box. > >2. Non-root users can install packages in the conventional way but > >in a private location using the -R flag. > > Which might be rather awkward because it requires an install with possibly > unwanted long pathnames under a user's directory. True. But in that case, is it possible to create a package that would install in the correct places when installed on the system (paths under /opt/FOObar) and under $HOME. I can imagine having to create 2 different packages anyway, with different layouts and build options. In that case, wouldn't pkgadd -R work? > >3. Users can set up personal software repositories in a manner that > >goes beyond the simplistic view in style 2. > > > >As I understand it, this proposal is aimed at style 3. > > I believe so, yes. > > >There's also a fourth possibility: > > > >4. There is a central repository into which users can install > >software without privileges, and the user environment mechanism > >knows how to pick up software from that repository. > > And users would not see other user's software? Perhaps; perhaps not. First off, I'm thinking of a per-system (rather than per-user) repository here. (I don't think it makes any sense to have shared per-user [as in dependent on $HOME] repositories.) So there's a dumping ground that users can install into. If a second user comes along it spots that what they've asked for is already installed, and doesn't install it again. The smarts here is really in PATH (et al.) management - that's what I mean when I say that there has to be some way for the user's environment to pick up that the app is installed and set up the user's account to use it. > >What I'm really after is a mechanism to - for users, not the > >system - eliminate any use of software management tools at > >all. Users shouldn't have to install applications at all, > >they should just work. > > That sounds like a plan. Are you thinking here of the > "download this file and run it" approach of windows installation? > (Where "run" does not necessarily imply a .exe) Ideally. We can do this with java today - just distribute a jar file and that's all you need. Or expand at first execution. No "management" at all. > >The primary use I would have for using pkgadd as myself is to be able > >to install a piece of software distributed as a package into a temporary > >location so I can repackage it in some more suitable format (such as > >a tar file). > > Another thought: should these packages be specific user relocatable > packages, relative to $HOME? So that's the point I made above about needing two packages - one for system use, another for UBI. > >It isn't clear to me that using $HOME as a default necessarily makes > >sense. For a single-machine setup, it doesn't matter where it goes; > >for a multi machine setup it makes more sense to me to associate it > >with a system rather than a user. Besides, I really want to avoid > >every user installing their own copy. > > $HOME is writable? Other locations which are user writable do not > necarily exist. So we create a standard one... -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
