I'd just like to point out that this proposal doesn't actually help with the issues brought up in UserProgrammableSecurityObjects, except for creating a root-level LoginManager^x, and that only if you don't have any kind of local roles computation. It doesn't fix local roles recursion or the encapsulation issue, so I would be wary of describing its scope as being an alternative to the things proposed in UserProgrammableSecurityObjects.

JimFulton (Aug 1)

I agree. It is only an alternative to the UserProgrammableSecurityObjects to the extent that UserProgrammableSecurityObjects solves this problem. :)

I also think we need to pay more attention to the issues raised in UserProgrammableSecurityObjects.

I do like this proposal.

I'd like to see it kept simple. For example, I suggest that we keep the semantics of the access file the same but make it optional and don't create it on install. Disabling superuser should be as simple as removing or renaming the access file.

I think that a way to address some of Phillip's concerns is to:

• Make LoginManager^x, or something very much like it a part of Zope and have the bootstrapping process create the LoginManager^x such that it contains the initial user. Then people can use LoginManager^x facilities to provide additional user/validation sources.

I don't have any objections to the idea of having a bootstrapped manager user, but I do think that that user still belongs outside the ZODB. Why? Well, what happens if you break your LoginManager^x and can no longer login? If you login as superuser and delete the LoginManager^x, now you're screwed because there is no way to repeat the bootstrap process. Unless of course you create some kind of API to do it with... Anyway, it seems to me you end up right back where you started: having to expand the access file or create another filesystem file in order to have a bootstrap user or user(s). It doesn't matter to me if you only allow one such user to exist, but I think that:

1. Having the user inside the ZODB doesn't fix the problem, and

2. Tying the bootstrap process to LoginManager^x is just as bad as tying it to UserFolder^x. It's a kludge point that creates an awkwardness for non-developers. While the access file approach may require an improved editor for the file, it's a much more understandable setup step for a non-developer than are magical and mysterious automatically added users that then disappear if they should delete something accidentally.

Of course, I'm basing these impressions on not having a clear vision of how a ZODB-based bootstrap user would really work. If somebody wants to expand on that...?