> >Sorry to confuse. I was suggesting a rule that says, as a class G user, > >you could target > >- XAUTOLOG > >- SET SECUSER or OBSERVER > >- SEND (a la class C) > >- FORCE (with a new class G version) > >- SIGNAL SHUTDOWN > > > >to any user to whom you are authorized for LOGON BY. Thinking further, > if > >you did not have LOGON BY, but did have XAUTOLOG authority, would it be > ok > >to implicitly grant FORCE and SIGNAL SHUTDOWN?
Not a good assumption. I think I'd argue that you should provide a way to individually control each command and ship that with CP. Long term, that's the better solution, and there's a load of stuff that you're dual-pathing now for people that do and don't have an ESM. Much as I dislike RACF, you'd be better off spending the effort to bundle RACF with CP and moving all the command authentication stuff to RACF profiles. You'd solve a lot of other problems in the process, and let sites determine this behavior more granularly than command classes permit today. It would also be a better technology argument vs VMWare and the other Intel virtualization solutions -- they're going to have to invent something very much like RACF in the near future, and you can beat them to the punch. Then you can start on command operand authorization...8-) -- db
