On Friday, Oct 10, 2003, at 07:29 America/New_York, Paul Smith wrote:
%% Martin Mewes <mm@xxxxxxxxxxxx> writes:
Obviously this now pushes the battle down into the trenches of exactly what commands constitute this set, with the tug-of-war between the developers' need to manage their desktop, the security team's need to keep things secure, and IS's need to keep a maintainable environment.
mm> In a smiliar environment and if the developers really need mm> administrative privileges we always drag them down to be careful mm> what they do, leave them the boxed cd-set or a carbon-copy and mm> tell them that they have to setup their system for themselves if mm> they broke it down. They have to take care for their backup and mm> so forth. If they want to be root - they are responsible.
Again, the main issue isn't IS. IS already allows Admin access to Windows desktops, for example. And, we already have a large group of people with full root access on their Linux desktop, through an exemption process (required for business reasons): the rule there is if you've messed around with your system then IS will spend 20 minutes (max) trying to fix it. If they can't fix it in 20 minutes, they'll offer to wipe/reinstall your system partitions. So far (after 7-8 months) we have had zero problems.
The _big_ issue is security, not support.
What kind of authentication is done at your site? I'm assuming since you've only mentioned NFS that you're concerned about users changing their UID and snooping around. What utilities would your users need to change their UID?
Keep in mind one of my favorite quotes about sudo from Linux Administration Handbook by Nemeth et al - "Generally speaking, any attempt to "allow all commands except..." is doomed to failure, at least in a technical sense." If I were you, I would create a very restrictive sudoers file and then add to it as your developers request new commands. Hopefully the requests will flow to a trickle after a few months and then you can come back and post what your list ended up being :-)
Jurvis LaSalle
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
