Dmitri Pal wrote:
JR Aquino wrote:
That was the original design, however I was told that this is not
something people will be interested in. Thanks for you data point but to
change it we probably need couple more data points and comments.
I would be very interested as to why there was resistance or a thought that people would not be interested in an design that scales.
I welcome them to post the solutions that they have found in granularly 
managing several hundred users access to thousands of servers with mixed access 
rights spread out into dozens of security access roles in LDAP/Kerberos/Sudo 
(not to mention automated service accounts that need to login to systems and 
perform various tasks).

With regard to administration I can possibly see that someone would feel that 
creating an entire group for a hand full of sudoCommands is a waste, however, 
with a full enterprise running across many servers containing users that are 
managing their own pieces of software in systems administered by separate 
groups...  Having to enter 20-30 commands for each sudo Role tends not to scale 
favorably for the administrator having to enter them.

With regard to PCI-DSS auditing, we have found that when an auditor asks which 
users have X set of commands against Y servers, it is significantly easier to 
say which group of commands is aligned with which groups of users against which 
servers in the fleet.  Vs... Having to perform a search in ldap for the 
particular strings that match the full path of the binary(s) that you are 
trying to account for.

I am open to alternative technical solutions that can solve the management of 
massive sets of systems though, so if the alternative is viable I'd love to 
hear it!

I completely agree with you but the main opponent of the idea is on
vacation now.
It will be unfair to revert in his absence without a majority.

Can someone else express his opinion on the matter?

One was performance, memberOf isn't free.

The second was complexity. Lets say you define command R and assign it to command groups A, B and C. The admin of group B needs to tweak the command a bit so he modifies R. This could have a negative impact on command groups A and C.

So for simplicity he may make a command T instead. And the admins of groups A and C, having seem the problem of R changing make their own new commands as well. So now 3 (or 4) commands all do more or less the same thing.

So the argument goes that for security and simplicity the admins will create their own rules every time they create an sudo rule (except perhaps in the initial config).



I feel inclined to agree with Dmitri regarding a deferral on the hostMask 
attribute for resource sake.  I tend to see the data center design to stick 
closer to hostname utilization, rather than subnets... I.E. people tend to put 
a mixed bag of servers in the same subnet, but they tend to make sure that like 
servers have similar hostnames or sane hostnames that can have a floating IP 
address in the case of clusering, or high-availability, etc, etc.  That is just 
my observation. Feel free to correct me if I am grossly out of spec for the 
rest of the industry.

This will really be a relieve not to support it for now.
Agreed, while Todd gave us a lot of flexibility by coding it to support 
subnets, even after working for an ISP that managed fortune 100 companies, I 
have yet to see anyone setup systems via subnet in such a way that you could 
segregate privilege escalation wisely.


~Using memberUser as slight of hand over netgroups~

It's my understanding that the sudo source does a "getent netgroup" style of 
lookup to search ldap for the netgroup... if that is correct, it may indeed be necessary 
to utilize the compat function to share the hostgroups with sudo...

The overall goal, again, being to eliminate duplication of info: prod-servers 
hostgroup == prod-servers netgroup... vs prod-servers hostgroup contains the 
same manually duplicated servers as prod-servers netgroup...

The problem is that it is reverse.
Since for IPA the host groups are primary concepts and the netgroup is
something we want to phase out the logic is the following:
* Hosts are grouped into the host groups.
* A netgroup is a shallow container around the host group.
In our model host group can be a member of the netgroup not vice versa.
But this is not related to the question at hand.

The question regarding memberUser is that the sudo spec allows using a
netgroup to refer to a set of users. This is really a atavism to use
netgroups to reference a set of users instead of a direct user group.
The question is: can we assume it to be an atavism and not support it.
I updated the page so this point is more clear.
Right, being that the netgroups can be setup to contain a dynamic object such 
as a hostgroup, you can continue adding and removing objects from the hostgroup 
and have the effects take place in the netgroup... in this way sudo can point 
to these netgroups as an interim means of bridging the gap until A: sudo can 
utilize sssd, and/or B: sudo adapts a more modern view of ldap management.
I see the confusion... no, I am afraid Todd and his ilk are currently not motivated to allow for the use of anything but netgroups to define your hosts in this way. I have had long drawn out mailing list discussions with that crowd and I have come to the conclusion that I will eventually need to write the patch and submit it for the coup de grace against netgroups and sudo.

We will cross this bridge when time comes. We have some thoughts and

Freeipa-devel mailing list

Freeipa-devel mailing list

Reply via email to