[Freeipa-devel] Sudoers schema

[Sumit Bose]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel