On Wed, 25 Aug 2010 14:08:34 -0400 Dmitri Pal <d...@redhat.com> wrote:
> Sumit Bose wrote: > > 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. > > > > > > Are you saying that we should use the original approach of having > command entries, command group entries and rule entries but not use > memberof plugin for commands that are members of a command group? > Simo can you please confirm that you are Ok with such approach? Wow, I missed a big thread here. I was the one that objected to the command groups of course, and I have to say JR Acquino has a good argument. If we can avoid using memberof and perhaps avoid nested groups for commands I think we should have a good compromise. although if we find that nested groups of commands are a must then using memberof will give us more advantages than not using it. In that case I am ok with using memberof even if it doesn't come for free. The UI might have to get smart in how it shows and later allows to modify stuff, but I think we can handle it. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
