Dave Miner wrote: > >>>>> Further, this proposal raises many more questions about the ability >>>>> of the package and patch tools to present a coherent view of a system, >>>> >>>> In this context they can't, and I don't think they should try. Only >>>> software that's "owned" by a specific system should be part of this >>>> view. Software that is "owned" by a user should not. >>>> >>> >>> Again, I disagree; did we suddenly decide that the network isn't the >>> computer anymore? And how would I, as an administrator, find the >>> software that has been installed? Write a big "find"? Why is it >>> necessary to force that cost onto the customer, where it's definitely >>> higher in aggregate as each customer has to come up with their own? >> >> What do you do with the information as a system administrator ? If you >> find out that user U has installed package P, how could you possibly >> rely on this information ? If you restrict (lock) the user in what he >> can do with P (like for example, remove it) then this is probably not >> what the user expect (he might have to free some diskspace to obey to >> the quota ...) >> > > Every user of a system is subject to some terms of use, and in those > terms administrators always reserve the right to take appropriate action > to eliminate threats to the integrity of the system. As an > administrator, when I hear there's a vulnerability in Firefox 1.5, for > example, it would be critical to my job to find out whether we have it > installed anywhere. Once I have that information, I can take > appropriate action; that might extend all the way to removing software > that a user has installed, or it might be something else entirely. You > may not like a particular response as a user, but that's the terms of use.
This is where we really disagree. I dispute the administrator to "always" have the right. If this is the case then there will be still some people who will prefer to install tar.gz's. > And actually, the more I think about this, the more I think that if we > do go forward with some form of this proposal, there might be an > argument to allow administrators to disable it either per-user or globally. yep. I'm pretty sure some customers would even insist on having control over that. >>>>> I'm interested in some elaboration of the DOS concern. I can >>>>> imagine some concerns, but I'd like to understand what you're >>>>> specifically trying to prevent. >>>> >>>> The system must not depend in any way on software that it does not own. >>>> >>> That doesn't answer my question in any way that is meaningful. What >>> is the threat that we're attempting to design against? >> >> that the system has a dependency on a package in the users home >> directory, or that user A's software depends on user B's. > > I agree that the former is probably almost always undesirable, but I'm > not so sure about the latter. But how do you really prevent it when you > introduce something with the flexibility of the Domain-Path proposed > here? And why shouldn't we be able to use Domain-Path for the root > domain? There may be cases where it makes sense. So I'm still not sure > what sort of denial we're really defending against. By creating a dependency from user A to user B you restrict what user A can do with his software in his home directory. He might want to experiment with it, remove every second library, install tuned versions that crash, and so on. To my mind there must be an option for user A to own exclusive, unshared rights to the software he installed. Other than that both users would need to get into a contractual relationship. A contract could be that user A has only the privilege to install the software but not to own/modify it. It goes to a common repository. When user B installs the same software or software that depends on it, then you increase a refcount. When A deinstalls the software only the refcount goes down. User A does not have the right to modify the software, only the system administrator does. - Christof
