Dmitri Pal wrote:

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
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.

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.

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.


Freeipa-devel mailing list

Reply via email to