Dave Miner wrote: > James Falkner wrote: >> >> >> Dave Miner wrote: >> >>>>>>> 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. >> >> The user-to-user threat that would exist would be that rogue user A >> installs >> a package into ~A that depends on nice user B's package. When nice user >> B goes to remove said package, they would get a failure, warning, or >> interactive question about breaking some rogue user A's package. That >> shouldn't happen unless nice user B wants it to happen, by putting >> A into their search/dependency domain-path. >> > > Thanks for elaborating on what you meant. I'd of course buy not failing > on DOS grounds, but I believe a warning/question is desirable as the > default. If we're going to enable users to cooperate, let's do it well,
It is the default, *if* user B acknowledges the existence of user A's dependence. The problem is that when user A installs a package that depends on B's package, B has no knowledge of this installation. So when B goes to remove their package, the tool does not know that A depends on it, unless 1) it does an exhaustive search of the entire filesystem, including network shares, starting at /, or 2) B provides a list of domains that potentially contain dependent software, or 3) both users install their software into a centralized registry or other repository, replete with with user administration and authorization capabilities, and can track and maintain dependency relationships across users/nodes/OSs/etc. While I agree that the latter is beneficial and I think would give you the administrative control you desire, I feel that this proposal does not preclude that in the future (in fact it takes a baby step toward it, by tracking cross-user dependencies in a scalable manner), while at the same time meeting many of the needs of customers who have been asking for this ability for quite some time. -jhf-
