On Fri, 2003-10-10 at 06:29, 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. > I don't have an answer and in the absence of any additional information, why don't you post the sort of things that you think theses guys will need to do and see if the list can come up with a way to restrict privs to those tasks. I would start with making the user member of the groups that run the services that they are going to be dinking with. then perhaps a list of config files that they can edit. This is not a trivial exercise. Bret -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
