[sudo-users] Offtopic: Re: sudo + ldap - nisNetgroupTriple

Jr Aquino JR.Aquino at citrixonline.com
Wed May 26 11:28:16 EDT 2010


Right, thats why I said role based access.

the sudo role can contain:

sudorole:

sudoUser: %someusergroup
userGroup: someusergroup

sudoHost: +somehostgroup
hostGroup: somehostgroup
hostGroup: nosudohostgroup

sudoCommand: ALL

someusergroup:
memberUid: username

somehostgroup:
host: hosta
host: hostb
host: hostc

nosudohostgroup:
host: hostd
host: hoste
host: hostf


I am not suggesting that the hostgroups or usergroups as they are  
represented in the role should double as both login and escalation  
rights. I define those separately with sudoHost vs hostGroup and  
sudoUser vs userGroup.

However I DO want to utilize the same sets of hostgroups / usergroups  
as they are static containers that define groups of hosts or users.

In this demonstration, username has login and sudo access to hosta,  
hostb, hostc, but it _only_ has login access to hostd, hoste, hostf.

Does this help ease the confusion?

On May 26, 2010, at 7:51 AM, Patrick Spinler wrote:

> On 05/26/2010 09:16 AM, Jr Aquino wrote:
>
>> As such, I'd like to have a list of hosts that both sudo and pam_ldap
>> can look to without having to duplicate the same data in 2 different
>> formats.
>
> Here's where I'd urge you to give careful consideration to your
> approach.  You're talking about using the same object type for
> semantically different purposes, and in fact to contain different  
> objects.
>
> *) A group of hosts for use in sudo rules
> *) A group of users for use in sudo rules
> *) A group of users to provision to a host
>
> In fact, these are all different, and *should* be represented
> differently in your repository.  We do something like this:
>
> auth_<somegroup>   - a list of people provisioned to a host
> sudo_<somegroup>   - a list of people granted a specific sudo command
> hgrp_<somegroup>   - a list of hosts
>
> Even in the first two instances, provisioning v. sudo, I *want* to  
> keep
> these separate.  For example, when an intern joins our unix team for a
> summer assignment, I probably want to allow that intern to log into  
> our
> machines so she can e.g. gather configuration info, but I probably  
> don't
> want to grant that intern the full sudo rights I give normal unix  
> admins.
>
> -- Pat




More information about the sudo-users mailing list