Christof Pintaske wrote: > 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. >
I don't think I argued he wouldn't have exclusive rights, I am attempting to argue that A should always be warned of dependencies, and that we should do everything we can to enable detection of those dependencies automatically, without the manual intervention that setting a mutual Domain-Path requires. > 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. > I don't think it's necessarily this complex. Trying again, what I'm suggesting is that we automatically register the domains as they come into existence, and that anytime an operation is done, we by default check the dependencies across those domains. I'm not demanding a shared file system repository of installed software, because that's counter to some of the project requirements. What I think is desired by customers in this case is a virtual view of the software system that encompasses all of the domains. Dave
