>>>> 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. 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. >>>> because that's not what they do anymore. We grappled with this in >>>> the zones space, and really didn't come to a resolution, punting due >>>> to lack of resources and time pressures. "Consolidation" is a great >>>> story, but if the consolidated system ends up requiring the same (or >>>> worse, new) expensive third-party tools to manage the software as a >>>> network of systems, then it's far less compelling. We know we need >>>> to do a bunch of work to make the user's software maintenance >>>> experience on Solaris modern and competitive, and I'm disturbed by >>>> the thought that this proposal will actually increase the scope of >>>> that problem without making any steps in the direction of addressing >>>> it. >>>> >>>> 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. Dave
