On Thu, Aug 19, 2010 at 02:47:33PM -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > >Hello, > > > >It occurred to me that we can have a compromise. We can have two ways > >and let the admins to decide which model to follow. > >So the schema will look like this: > >The sudo rule entry will have a string attribute to put a command > >verbatim as it is designed now and an attribute that contains a DN of a > >group of the commands (or points to commands individually). > > > >It seems though that instead of having separate objects for a command > >with just one attribute (the command itself) and then have an group of > >commands object with pointer to individual commands we can have just a > >command group object with a multi value attribute for commands entered > >verbatim. > >This way we probably even do not need to have two attributes as I > >proposed above. > > A creative solution but I'd almost rather go with the complex way > than this. If you wanted to change a command-line you'd have to > manually go through all the groups and change them one at a time. > > I'm not 100% opposed to the command and group-of-commands interface > I just wonder if in the typical case it isn't overkill. For those > with thousands of sudo rules it may make a lot of sense. My initial > objection was it seemed to be over-engineered, a Bentley when a > Pinto would do :-) > > > > >Sorry for designing on the fly. > >So options are: > >1) Leave as designed - does not provide a good role management (Nack) > >2) Revert to original - too complex and limiting (Nack) > >3) Have a hybrid of 1)& 2) represented by two attributes > >4) Make the rule reference an object named command group. The command > >group object will have a mv attribute with the commands > > > >IMO the last one is the simple compromise that addresses both concerns. > > Let me tell you how this would work on the command line. We'd likely > have 3 plugins (I'm not married to these names, they are just > illustrative): > > - sudo_cmds: CRUD for managing the individual commands > - sudo_group: CRUD for grouping sudo_cmds into groups of commands > - sudo_rules: CRUD for managing the rules themselves, the core of > which assigning sudo_groups and/or sudo_cmds to it.
+1 if we want to have groups we should use this design, because this is the way other objects like hosts or services are handled in IPA. > > I gather that a sudo command would use the memberOf plugin to be a > member of a sudo group, right? Could that be skipped? It does help > us know what groups use a given command but we can run a query to > find that if necessary. That might alleviate Simo's concern that > memberOf isn't free. As Jakub mentioned earlier sudo creates search filters based on the user and his group memberships. So I think the memberOf plugin is not needed. bye, Sumit > > The other problem with multi-value commands is we don't yet have a > nice way on the command-line to manage them. You'd want to be able > to do things like "delete the 3rd of these 5" or "modify the 7th one > to this", etc. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
