On Fri, 24 Aug 2007, Alan Altmark wrote: > There are some who believe that the authority to LOGON BY to a user should > implicitly allow: > - XAUTOLOG > - SET SECUSER or OBSERVER > - SEND (a la class C) > - FORCE > - SIGNAL SHUTDOWN > > Thoughts?
And maybe FOR, in 5.3. At my current job, we create LOGONBY profiles out of laziness - small group, development shop, most of us log onto multiple ids every day, so no one has to remember (or change) any password but their own. In this environment, there would be no issue with bundling all of that with LOGONBY. At my last job (security weasel for a RBC), surrogate facilities like LOGONBY were mostly used to solve the problem of how to provide accountable access by multiple people to a shared security principle (userid) for administration or maintenance, with convenience way down the priority list. Frequently, there was an implied serialization of the resource, too. There, we wouldn't have wanted to see something like this because it would have made collisions less likely to be detected before something bad happened, and auditing more complex if it did. The logic of "but they could do it anyway if they can log onto the user" is hard to argue against. The question is whether there is really any difference that matters, other than maybe the serialization thing, between doing something while logged on as a user and doing more or less the same thing as or to that user while loggged on as a different user. Steve -- Steve Marak -- [EMAIL PROTECTED]
