> I'm not sure what you're suggesting as far as this > proposal, but using zones > or changing the zones implementation to provide an > even lighter weight zone > than a sparse zone, in order to allow non-root users > to install mozilla or > vim, still sounds like the wrong tool for the wrong > job. >
Why it sounds like this? We have to povide isolation between software domains anyway for concurrent or incompatible software and zone alredy doing it pretty well. I think that providing similar to zones isolation wil require similar to zones project effors to implement. Isolation should be in place and why not to use zone isolation. Everything may be shared but some specified filesystems - like /opt (it is just idea not proposal, yet). We already have everything to work in enviroment that shared, install support for zones was made flexible in terms of what shared and what not shared - list of shared filesystems as I remember. Installation, packages, patches work with zones alredy. So I do not see too much troubles to implement it and in terms of resources - also should not be too expencive, it was only area which suppose to be different will not be shared. I am not sure what will it mean for kernel - I'll talk to them, but otherwise such an implemetation of software domains sounds pretty natural. Of course with plugins for browser I rather have it as part of user configuration instead of user based installation. As a former sysadmin for Insurance company I rather will not allow my user to install any browser plugins they found on internet but better ask me to do this first. Also may be I am wrong but customer for this feature more like some king of user, departments etc. Like group of developers which need to manage tools independently from sysadmin, or group of analists who need their own Sas installation tuned up for theis tasks or something like this. > We have the ability to provide coarse-grained > packaging management rights to > users (i.e. you can manage all packages, or none). This is not practical - nobody will grant regular user to manage everything. > Finer-grained access > ontrol for managing individual packages sounds great, An this is what everybody asking for. > but still requires > admin intervention, and the number of possible > scenarios with issues > would grow quickly. For example, if a patch crosses > between two different > sub-administrators, who is allowed to install the > patch? This problem we will face anyway with any kind of "Non root install", and we will have more and more, just because of dispersing software. Of course the number of possible scenarios with issues would grow quickly just because we introducing new dimention of complexity. In this particular case answer is pretty clear and straitforward - only one wich has right to update both packages should be allowed to do this. So sysadmin or some other sub-admin with required privelege will do this if this happen, which is unlikely. But still admin intervention will be required to grant priveleges, still software should be grouped into what is ok to install by one or another user and what is not. You can not allow anybody download anything from Internet and install. I am getting more and more confident that "User Group Zone" is the only solution. Of course if kernel say that it is possible and not to hard to do. I'll ask kernel guys to have a look at this. Thanks, Vassili. This message posted from opensolaris.org
