Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux in a Business - Got Root?

Cliff posted more than 8 years ago | from the control-your-own-destiny dept.

Unix 464

greenBeard asks: "I work for a government contractor, and have recently convinced them to purchase a Beowulf cluster, and start moving their numeric modelers from Sun to Linux. Like most historically UNIX shops, they don't allow users even low-level SUDO access, to do silly things like change file permissions or ownerships, in a tracked environment. I am an ex-*NIX admin myself ,so I understand their perspective and wish to keep control over the environment, but as a user, I'm frustrated by having to frequently call the help-desk just to get a file ownership changed or a specific package installed. If you're an admin, do you allow your users basic SUDO rights like chmod, cp, mv, etc (assuming all SUDO commands are logged to a remote system)? If no, why don't you? If you allow root access to your knowledgeable users (ie developers with Linux experience), what do you do to keep them 'in line'?"

cancel ×

464 comments

Sorry! There are no comments related to the filter you selected.

SUDO Commands (1, Offtopic)

Traxton1 (154182) | more than 8 years ago | (#14362665)

You forgot AIII-YAAA!

Change Management (1)

oc-beta (941915) | more than 8 years ago | (#14362841)

Is very important in high availability environments. I find that a lot of times, due to lack of communication, I will change something on a server, and another admin will come along. "Who the heck did this?" And change it back. So I end up spending a good portion of my day doing things a few times. Now, I would implement change management if it were a high availability system. Instead it is just our dev network.

Re:SUDO Commands (5, Informative)

mrbooze (49713) | more than 8 years ago | (#14362889)

I don't really get the original premise. Nobody needs to be root to run chmod, cp, mv, etc on their own files. The only command mentioned one might need root for is chown. Which would make me ask the question, why do you need to change file ownerships so often?

It would take a hard-core serious business case to convince me to grant someone root access, even sudo-limited root access to a production system. The fact that I might have a "log" of whatever broken thing they did to take a business critical machine down is fairly irrelevant to me. My job is to make sure that doesn't happen in the first place.

Hell no (1)

Anonymous Coward | more than 8 years ago | (#14362666)

Because if you allow someone chmod permissions, for example, all they need to do is something like "chmod 777 /etc" and you're system security is screwed.

Re:Hell no (0)

Anonymous Coward | more than 8 years ago | (#14362743)

No, not if you set it up properly.

Hell yes! (1, Funny)

Anonymous Coward | more than 8 years ago | (#14362832)

I liked it so much, I pwn3d the company!

Re:Hell no (0)

Anonymous Coward | more than 8 years ago | (#14362863)

That is providing they are in the "Wheel Group". Are you giving priv access to a group?

Don't give them full control (2, Insightful)

Architect_sasyr (938685) | more than 8 years ago | (#14362667)

I usually write kernal modules that nerf certain permissions.

This way, users can do what they like, but they can't fsck anything up.

Failing that, I reckon a big man with a large knife could probably go a long way to keeping them in line.

Re:Don't give them full control (3, Informative)

slashjunkie (800216) | more than 8 years ago | (#14362709)

Can't SELinux achieve this (ie, fine grained security access control within the kernel)?

Re:Don't give them full control (1)

Architect_sasyr (938685) | more than 8 years ago | (#14362728)

Probably can, but I have too much trouble (as in, I don't have the time) re-configuring everything to work around the thing. The modules I can write in my own time, and they are easily updateable. Fighting with the SE just isn't something I'm up for. It probably is easier to use, but when you know something well already...

Users != Root. (5, Informative)

paitre (32242) | more than 8 years ago | (#14362668)

Much as I hate to break it to you - this is SoP.
End users Do. Not. Get. Root. Even allowing SUDO access to change file permissions, copy, or even move files is just asking for trouble.
Installing software or libraries? Hell no. Not on a live system.

If they have a development-type machine at there desk, that's one thing (just don't call for support if you break the damned thing). Even then, my preference is that they have limited access.

On large, shared systems, users get as much, and as little, access to do their jobs as necessary, and absolutely no more than that. I have to keep the system up for other users, I can't have power-user #1 screwing things up by changing permissions on something they really shouldn't be touching (let's take the compiler for example...)

A little knowledge makes one dangerous, and I'd just as soon noone other than those paid to admin the machines have access.

Re:Users != Root. (0, Interesting)

Anonymous Coward | more than 8 years ago | (#14362699)

"If they have a development-type machine at there desk, that's one thing (just don't call for support if you break the damned thing)."

The reason of existence for you, IT Lackey, is to make sure my machine is working. Then I, god-like Software Developer, can develop the company product which in turn gets sold by the rat-faced vermin in Sales and Marketing.

IT Lackey not giving support => IT Lackey should no longer be employed.

Re:Users != Root. (0)

Anonymous Coward | more than 8 years ago | (#14362739)

note - government contractor. there's probably regulatory/etc. requirements (in order to ensure no backdoor code, etc.; what if Iran offers mucho money to someone to insert code? etc.). your example does not apply.

Re:Users != Root. (2, Interesting)

tomhudson (43916) | more than 8 years ago | (#14362776)

You're not a developer if you can't even maintain your own machine.

To be a decent developer, you have to understand not just how to write code (or, in too many cases, "move pretty icons on a screen") - you have to understand the environment it runs in, including file permissions.

  • You break it - you fix it.
  • You malloc it, you free it.

Didn't your mother teach you to clean up after yourself?

IT Lackey not giving support => IT Lackey should no longer be employed.

So-called "god-like Software Developer" can't even maintain his own machine => waste of skin exposed.

Re:Users != Root. (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#14362800)

I have better things to do than install security patches and fiddle with hardware. That is why IT monkies like you have jobs. This is also the same reason I expect the maids to clean up my hotel room.

Re:Users != Root. (0, Flamebait)

Anonymous Coward | more than 8 years ago | (#14362874)

I suggest you start reading BOFH [ntk.net] and get prepared to have your attitude adjusted someday.

Re:Users != Root. (2, Interesting)

Anonymous Coward | more than 8 years ago | (#14362721)

all well and good but I have worked in places where I definitly had more skills than the admin and had to wait long periods of time for the inept admin to fumble their way through somthing I could do in 5 seconds.

Users != Root on servers, not workstations (2, Interesting)

DonGar (204570) | more than 8 years ago | (#14362835)

One variation that I've seen work well is to allow people full access to their own workstations, but not on servers (or clusters in your case).

This limits the types of access people can have on the heavy server machines, but lets them install apps or do whatever they need locally, including installing a different OS or OS variation based on need or preference.

Of course, the more people 'adjust' their workstations the less support you can afford to give them. You also have to be very careful about how much servers trust any information from workstations (NFS can be very tricky to get right), and have to more draconian with your firewalling policies.

Security versus usability is always a balancing act. It just depends on which balance is right for your environment.

Re:Users != Root. (4, Insightful)

Frumious Wombat (845680) | more than 8 years ago | (#14362850)

Good for you. I don't give myself privs on the system (I have a separate account for root-access), and I'm certainly not giving people who aren't familiar with all of the ins and outs of a production system access. I am most certainly not giving developers, who have a tendency to muck with libraries and paths to solve problems, access, even if its logged. Being able to yell at the specific miscreant later really is poor compensation for having to take a production system down, repair their handiwork, and deal with the rest of the angry users.

I used to deal with this on our production cluster all of the time. I implemented a pretty rigid policy early on, which was no root for users on anything that was (1) in production, or (2) had access to the various network servers. This policy came about after a few 'experienced' users demonstrated their skills. Accidentally changing access privs and ownership of the /Users directory tends to raise sysadmin blood pressure, as does nuking /etc, thinking it was ~/etc, or updating a system library to fix your program, which then breaks production codes that people are actually using.

The problem always seems to be that people who've admined their own, solitary, system, think that experience automatically translates into full privs on a much larger, integrated, environment. This is where I miss VMS, and its fine-grained privs. I'm not sure I'd hand those out either, but at least it's better than all or nothing. The next best solution is giving developers access to a box that you can nuke and reimage back to a standard state, and letting them hack with that.

sudo chmod == pwnt (5, Insightful)

qweqazfoo (765286) | more than 8 years ago | (#14362671)

Ever heard of setuid root?

Home-grown setuid programs are dangerous (0)

Anonymous Coward | more than 8 years ago | (#14362724)

If you don't do them right, users can exploit the IFS and PATH envvals to subvert your setuid wrapper program.

THis is where I miss VMS (4, Insightful)

Billly Gates (198444) | more than 8 years ago | (#14362674)

ACL's are quite nice and so are different levels of security.

Re:THis is where I miss VMS (2)

slashjunkie (800216) | more than 8 years ago | (#14362732)

Several filesystems on Linux have support ACLs for a couple of years now... ext2/ext3, ReiserFS, XFS....

Re:THis is where I miss VMS (1, Funny)

foxhound01 (661872) | more than 8 years ago | (#14362765)

Yeah, ACLs are nice. A buddy of mine tore one of his while playing football almost a year ago and is just now getting to where he can walk normally.

Tie them up! (0)

Anonymous Coward | more than 8 years ago | (#14362677)

We usually just tie them to their chairs with duct tape. That way we always know where they are, and what they've done (the video cameras help).

Re:Tie them up! (1)

boarder8925 (714555) | more than 8 years ago | (#14362729)

We usually just tie them to their chairs with duct tape.
That duct tape's got to put a strain on their use of the computer, what with their arms immobile and all.

But worse yet, think of the residue the duck tape will leave on the chairs!

Re:Tie them up! (2, Insightful)

eln (21727) | more than 8 years ago | (#14362831)

Good thinking using both forms of the term duck/duct tape so as to avoid any potential flames about spelling it wrong. You, sir, are a born diplomat.

Of course, this being Slashdot, the more likely scenario is flames coming at you from both sides. Good effort, though.

Environment? (0, Insightful)

Anonymous Coward | more than 8 years ago | (#14362681)

IMHO, this will depend on the environment you are running. If you have some development servers, your users are most likely to be developers, who will require full (or close to full) access to the servers. In your staging environment you may want to start logging all the commands, and provide only limited sudo access. In your production environment - why would you have users in the first place?

Sarbanes-Oxley? (2, Informative)

pbrammer (526214) | more than 8 years ago | (#14362685)

Do you fall under the scope of the Sarbanes-Oxley act? By not allowing sudo or plain 'ol root access, accountability goes way up if you have to call the help-desk to perform whatever action you need to take. You have effectively limited the scope of those who can make changes to the system and presumably the changes that are made are logged.

Two names... (4, Insightful)

toupsie (88295) | more than 8 years ago | (#14362689)

Sarbanes and Oxley [sarbanes-oxley.com] . I don't know you, you don't need that access, we have a process in place and I am not signing off on you. Follow the procedure or go somewhere else to work.

Re:Two names... (0)

Anonymous Coward | more than 8 years ago | (#14362810)

Change Control - if you want a secure IT environment, you don't let just anyone make changes - whether it be administrators, business owners, etc. How do you know the change you're about to make isn't going to affect other applications or services? ITIL would be a good starting point for reading

It's just not safe... (5, Informative)

Jamori (725303) | more than 8 years ago | (#14362690)

Allowing root access on a knowledgeable user's local machine is one thing, but multiple arbitrary people with root on your main cluster is entirely another matter. There are simply far too many chances of one of them "accidentally" doing something they didn't mean to and borking the system. That's definitely not an issue you want to deal with.

And even allowing chmod, mv, etc via sudo can be dangerous. Someone accidentally issuing a "sudo chmod 777 -R / ", having meant to type "./" for everything below their current directory, isn't going to be good for your system health and is going to be somewhat of a pain to recover from, even if you do know who screwed things up.

Re:It's just not safe... (1)

Jamori (725303) | more than 8 years ago | (#14362723)

By the way .... I speak from experience on a small server I ran for my friends and myself. I got tired of tweaking things for them, setup some extra permissions for the ones I thought I could trust, and regretted that decision for the next several days.

Cynical answer (1, Informative)

Theatetus (521747) | more than 8 years ago | (#14362695)

OK, here's my cynical answer as a UNIX admin: I limit user access because it's one way to keep my position appearing valuable. As long as I'm the guy they have to go to for any system changes, and as long as I can tell the PHB's I'm monitoring their activity, my job sticks around.

the way I do it... (5, Interesting)

Heem (448667) | more than 8 years ago | (#14362698)

You are going to get a bunch of responses. most of them from people that will say something like.. "NO." "NOBODY GETS ROOT, PERIOD".

Well, in an ideal world, it would be that way. We would setup systems for people to use and they could just use them without root privledge. Unfortunatley we know that isn't possible if you want your users to actually be productive and get things done.

I work for a large software company. Trust me you'd know the name of it if I could tell you. We use linux on the desktop, as well as the servers. We also have some Microsoft servers that are either for legacy purposes (havent been updated yet) or for testing applications against MS environments. Anyway...

All my users have laptops with Linux on it. They all have the root password to their individual laptops. Many of the also have a server at their desk for their own testing purposes. They have root to that.

However, the "real" servers that are accessed by someone that isn't themselves, the users do not get the root password, ever.

I look at it this way. If you bomb your laptop or your test server, either you can fix it, or you can call me and I'll walk you through fixing it, fix it, or just give you a new clean configuration.

If you bomb my server, I'm going to make sure you never have access to anything, ever.

Re:the way I do it... (1)

Vellmont (569020) | more than 8 years ago | (#14362754)

I think your shop is pretty typical. For a software developer there's a lot of reasons why you should give them root access to a non-shared machine they use for development and/or testing. Giving root access to a developer on a shared, production machine, no matter how competent an administrator they are is just bad policy.

Sudo on shared test machines can be a bit more liberal though. Much of the time developers need to start and stop services multiple times a day, if not an hour. It's impractical and extremely inefficient for a developer to have to ask an admin to do this multiple times an hour.

What I'm getting at is sudo should be relegated to high-level tasks like starting a specific service, and not low-level tasks like (gasp) chmod and mv. You can easily do an ENORMOUS amount of damage with the wrong sudo mv command.

Re:the way I do it... (1)

Heem (448667) | more than 8 years ago | (#14362771)

and as good a developer or QA engineer they may be, they are not the ones accountable for the systems. at the end of the day, I, and only I am accountable for building and maintaining good systems.

Re:the way I do it... (1)

thesnarky1 (846799) | more than 8 years ago | (#14362797)

I think you're absolutely right in this. In my mind, it's all a matter of damage control. If someone screws their (personal, not shared) development system you're out one programmer for maybe a coupla hours. If someone screws a production server, or something a lot of people use, everyone's down until it gets fixed. In my mind, a user should never be allowed permission to do something that could affect more people then themselves, unless they are well-trusted. Such as an admin in this case. They get permissions because they are trusted to not screw something up, and be able to fix it even if they do.

Re:the way I do it... (0)

Anonymous Coward | more than 8 years ago | (#14362818)

I work for a large software company. Trust me you'd know the name of it if I could tell you. We use linux on the desktop, as well as the servers

Novell?

Re:the way I do it... (1)

tyler_larson (558763) | more than 8 years ago | (#14362852)

You are going to get a bunch of responses. most of them from people that will say something like.. "NO." "NOBODY GETS ROOT, PERIOD".

And, of course, "Shame on you for even asking!"

Even the "innocent" looking commands like chown and chmod can have profound effects when run by root (setuid anyone?). Logging behavior is no solution--you'll have the logs, but the damage will be done. And as with any other r00ted system, the extent of the damage is never really certain. Even the integrity and completeness of the logs would be suspect.

Giving users sudo access is giving them the ability to execute any attack you haven't specifically guarded against. If there's any priviledged operation that users need to perform, it should be properly wrapped in a tightly controlled setuid binary.

Re:the way I do it... (1)

ryanov (193048) | more than 8 years ago | (#14362879)

You won't even have the log, if it's local and the user removes it.

XEN (0)

Anonymous Coward | more than 8 years ago | (#14362704)

xen is the king. ( http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ [cam.ac.uk] ) Many ISP who prowide virtual hosting provide you a xen machine instead - you have a full root access in a chmod jail, they have several VMs w/o perf penalty. Not your case though...

At the risk of saying obvious (2, Interesting)

superwiz (655733) | more than 8 years ago | (#14362705)

Have them share a group? They can always share files by allowing complete group permissions, can they not? If that is all they want to do.

Nope. (2, Insightful)

Onan (25162) | more than 8 years ago | (#14362706)

The next time that server blows up and needs to be replaced, or we simply decide we need to add another one, building it is my problem, not those developers'. And it's a whole lot more problematic if I don't know all of what was done to get it into its current state.

Of course, that really just goes back to the fact that you should never do anything adminnish directly on a single server, ever. Your configuration management tool should do it for you, so it will also know to do it to the next one.

Support support support (0)

Anonymous Coward | more than 8 years ago | (#14362711)

Some of the systems I work on (high end compute clusters used by hundreds of researchers around the country) are very very restrictive. Do whatever you want inside your ~, but nothing outside. Why would someone need to change the permissions on a dir in /usr? /lib? It's a live system, and clusters need to stay up :-)

Need some software installed? Hell yeah - call support. Want to make it less frustrating for users? Have really really good support people (person), who knows the system VERY VERY WELL.

No way in hell! (0)

Anonymous Coward | more than 8 years ago | (#14362712)

If you let developers change anything at all on a machine, change control goes out the window. When they deliver their product and piss off to a better paying job elsewhere you have no way to reproduce whatever weird arse thing they did to get their software to run.

Keep root away from developers and other users. Always. Never ever give in. Relax your guard and you will be bitten!

Imagine a Beowulf cluster of (1)

davidwr (791652) | more than 8 years ago | (#14362713)

Oh wait. Okay, everybody can groan now.

Seriously, people should have the minimum permissions necessary to do their day-to-day jobs.

When it comes to things they might need to do occasionally, you have to decide is it worth the risk to give them that level of permission.

One way that might work is allow "sudo for a day" with management approval. If a person needed to do more than one thing in a day (or hour, or week) that needed extra privilages, have his manager and the IT manager sign off on it and give him those extra privilages for that time period. In some cases, this might mean adding him to the sudoers list.

If it's just a single task, like install a package, might as well have IT staff do it since it'll be just as much work to get management approval.

not root, but ..... (2, Informative)

skelley (526008) | more than 8 years ago | (#14362716)

.... we run a SOA enviroment with about 50 different apps on many machines. We run each app under a seperate uid. App developers are in a group named for the app and members of that group are given full sudo permissions for the app uid. Creative use of /tmp and cp have eliminating most of the chown requests. Only issue is for those few developer's than need to work on more apps the the 32 group limit allows. They have to suffer with the newgrp command.

Root in dev environments only. (5, Informative)

Uhh_Duh (125375) | more than 8 years ago | (#14362717)

Developers with Linux experience are a LOT more dangerous than developers without linux experience. My experience has been (100% of the time) when I give "experienced developers" access to commands like 'chmod', I find all kinds of files mode 777 (among a list of about 10,000 random, stupid things developers do) because, well, I've heard pretty much every excuse you can imagine.

The problem is that as soon as people outside of the core sysadmin team have access to critical system commands (cp, chown, chmod) the integrity of the box is left to chance. There's always the possibility someone is going to do something outside the policy. Sysadmins make it their job to know and understand the impact of every change to a box. Developers tend to make changes in order to get their stuff to work, regardless of the consequence (hey, each group is just trying to do their job, which is "make it work!!" -- I'm not defending either side).

My rule of thumb:

- Developers get root in their dev environments.
- Sysadmins get root in the production environments (developers shouldn't even have user-level logins to these machines.) If your company is releasing software (even for internal use) properly, the IT group will be managing the code as a product, using developers as a help desk rather than letting them manage the applications directly.

Stick to this and everyone will be happy.

Re:Root in dev environments only. (1)

{X-Frog} (122801) | more than 8 years ago | (#14362756)

yep, I totally agree with you.

I always ask users to install their applications under an application username and group, this stop all problem and software/dba admin can do their job without asking someone else to run a command.

If this is an old application that must be run in root, I add some of the command that he must use, for that application only, in a sudo file. It doesn't cause problem if you inspect files/script before adding them to their sudo.

Developpers and dev-group/machine, in my experience, always had their own systems, with root access, in a different network. All I do for them is installing the system and configure the network, after that, it's their machine and if they ask me to repair it, they must have a pretty good reason (and escalation)! hehe

Re:Root in dev environments only. (1)

Knetzar (698216) | more than 8 years ago | (#14362760)

My problem comes from when I see operations not have root on production servers. They need to call another group to do server specific stuff even though their app is the only thing running on the server. Does that make sense?

Re:Root in dev environments only. (2, Interesting)

GoofyBoy (44399) | more than 8 years ago | (#14362789)

Yes it does.

Its usually the other group's reponsiblity to have the box and app running. That means changes are well communicated and planned, not ad-hoc.

Also, its to make sure the single app is the only thing running on the box.

Also, its to make sure that there is a known level of security on the box.

Re:Root in dev environments only. (1)

Knetzar (698216) | more than 8 years ago | (#14362813)

I'm sure that's a good idea, but when the team that owns the box is overworked, it can slow things down.

Re:Root in dev environments only. (1)

duffahtolla (535056) | more than 8 years ago | (#14362849)

That is the price of stability.

Let me be the first... (1)

TubeSteak (669689) | more than 8 years ago | (#14362720)

To suggest that you install a rootkit on the computer you need to use.

As for keeping them 'in line' once they have root access... I recommend a pointy stick.

Umm... or training. Even knowledgeable users can accidentally forget to reset permissions up and since you're a gov't contractor, you have to be more careful about data security. Right?

I couldn't do my job without root access (5, Insightful)

unixpro (464350) | more than 8 years ago | (#14362725)

I come from the other side of the fence. I am a developer of multiplayer servers. For my part, I couldn't do my job without root access. I need to do things like set the date and time on the machines, install to /bin, upgrade compilers, etc. If I had to ask the helpdesk every time I needed root, they'd just set up right outside my cube.

On my Windoze machine, OTOH, I have no need for system level permissions, and I don't ask for them. I can install software, but so can all the other developers (and, I think, anyone in the company). All I use that machine for is e-mail and testing client connectivity to my servers, when I'm not using my Linux test client.

Some people need root and some don't. Don't make blanket policies unless you're prepared to make exceptions. Oh, and, for everyone's sake, if you do restrict access, please, please make sure that at least one person who can change things is available 24/7. I can guarantee you that Peterson up in Accounting is going to have a system crash that requires help when trying to get the year-end reports out at 2:30 A.M. before the big board meeting at 9:00.

Is your to-do list finite and predictable? (1)

davidwr (791652) | more than 8 years ago | (#14362774)

It's a given that your "must have root to do this" list is finite, but is it "smallish" and something that can be predicted in advance?

I ask because if you only need to do a few dozen things over and over again, the admins could configure the system so you could do your work without root.

On the other hand, if your "must be root" tasks are new every day then you might as well be a system administrator. Just be sure you keep the real sysadmins up to date with any changes you make. Change control is important you know.

Re:I couldn't do my job without root access (1, Troll)

GoofyBoy (44399) | more than 8 years ago | (#14362811)

>I am a developer of multiplayer servers. For my part, I couldn't do my job without root access.

If you are a developer, you don't need root access. All the examples you've given are the system admin job (system administration?)

>Don't make blanket policies unless you're prepared to make exceptions.

Its not really a blanket policy if there are exceptions.

Re:I couldn't do my job without root access (1)

Onan (25162) | more than 8 years ago | (#14362876)

If you're messing around the the date and compilers on live production servers, you've got bigger problems.

If you're doing these things on a development system that's hermetically sealed from the production environment, that's only medium bad--but it's also a separate issue from what the original submitter seemed to be asking.

Don't forget userlimits! (1)

hamfactorial (857057) | more than 8 years ago | (#14362726)

Surprising numbers of linux admins aren't aware of this simple BASH forkbomb:
$ :(){ :|:& };:
It can be stopped by setting good ulimits, otherwise any old shell user can bring down a server in seconds.

Re:Don't forget userlimits! (1)

Morlark (814687) | more than 8 years ago | (#14362773)

Ah, that's a classic one. Brilliantly simple. We had a server go down when somebody accidentally typed it into the wrong terminal while trying to test the ulimits on their local machine. Oh, we all had a jolly good laugh about it afterwards of course.

Dear slashdot... (4, Insightful)

GoofyBoy (44399) | more than 8 years ago | (#14362737)

... I'm special and rules don't apply to me.

How can I convince others of this?

Re:Dear slashdot... (0)

Anonymous Coward | more than 8 years ago | (#14362814)

Rename yourself Microsoft
Rename yourself Sony
Consider starting a cult
Break the law and don't go to jail
Stop hiding your 6-fingered hand when talking to people ...

Oh wait, you were trying to make fun of the submitter.
You got me stumped there GoofyBoy

That's easy. (0)

mnemonic_ (164550) | more than 8 years ago | (#14362751)

Just hack the code, Neo.

The keys to the kingdom (1)

ClickOnThis (137803) | more than 8 years ago | (#14362753)

It is best to have one and only one person with root access, even if your users are knowledgeable and honest. This eliminates the chance that two or more users could make changes to the system that, together, compromise its security or stability. Also, if something goes wrong, it's alot easier to know who did it (!) and what needs to be done to fix it.

Re:The keys to the kingdom (1)

leenks (906881) | more than 8 years ago | (#14362802)

Let's hope he never gets sick, eh?

Re:The keys to the kingdom (1)

ClickOnThis (137803) | more than 8 years ago | (#14362860)

Let's hope he never gets sick, eh?

If s/he gets sick or goes on vacation, s/he can always change the password temporarily and designate an administrator pro tempore. Also, it's trivial to break root in an emergency if one has physical access to the machine.

The point is that only one person at any time should have root access.

Users are stoopid? (2, Insightful)

Gilmoure (18428) | more than 8 years ago | (#14362757)

Even the smart ones. Sure, give the users some stand alone development machines with root access but don' let them fuck up the cluster/servers. A lot of users are focused on their job but they don't always see how their actions on shared equipment will impact the company or entity at large. /tech support at large lab, full of brilliant idiots.

Simply put... (1)

Solokron (198043) | more than 8 years ago | (#14362769)

because "it was an accident" does not cut it when a production server goes down. They getting fired or not because it was logged does not help the fact they hosed a server that needs to be running.

Need more info (4, Informative)

Frohboy (78614) | more than 8 years ago | (#14362770)

This sounds to me kind of like the situation in a university Unix network. I'm not entirely sure I understand what you necessarily need that wouldn't be available (though I would like to know, to get a better understanding of the question). Certainly, at the university I attended [uwaterloo.ca] , we didn't have sudo access, but we were able to develop some rather powerful applications.

I can see an adjustment period of a couple of months, where applications you regularly use aren't available, so you ask for them to be installed. After that, assuming they don't see the general need for an application (or they don't want to have to officially support it), you could theoretically install applications under your home directory. (I was thrilled when I became a grad student, and got 100MB of disk quota, so I could compile and run Blackbox as my window manager instead of the crappy twm we were generally stuck with. In fact, I made it globally executable, so my friends could use it as their window manager. In fact, I received a phonecall once from one of the admins, asking me what this spinning "blackbox" process was running on one of undergrad servers, since I was the only grad student or professor (and therefore in the phone directory) who also ran it.)

These days, as part of my regular job, I am one of the unofficial sysadmins of a Beowulf cluster (largely because I'm the one of the only ones who have developed MPI applications that run on it). I get the odd request from other users who want me to hook them up with some library or such. I compile and install it under /usr/local/whatever, and tell them how to set up their LD_LIBRARY_PATH to link against it, and they're good to go.

Again, I have to ask what you need that requires root or sudo access, that can't be solved by the rare admin call or installing under $HOME. (I really don't mean this in an insulting way. I do want to know. The story post is a little brief.)

Re:Need more info (2, Interesting)

markrages (310959) | more than 8 years ago | (#14362869)

Speaking as a former user of such a university computer, I was *glad* not to have root access on my machine. It removed the burden of system administration, and left me to concentrate on the stuff I was supposed to be working on.

UNIX permissions are designed for just this situation, allowing users to work freely without giving them ability to break the system. Why is the orginal poster trying to circumvent this?

Re:Need more info (0)

Anonymous Coward | more than 8 years ago | (#14362883)

In fact, I made it globally executable, so my friends could use it as their window manager. In fact, I received a phonecall once from one of the admins[...]


Gah... just noticed I started two sentences in a row with "In fact". This is just like grade 10 public speaking all over again. I suck at composing interesting sentences off the top of my head. (Posting anonymously, since this is useless, and just here to head off people getting funny mods for ridiculing me. Of course, modding this "funny" is totally kosher.)

Root Access? (2, Informative)

DA-MAN (17442) | more than 8 years ago | (#14362778)

I work for a government contractor, and have recently convinced them to purchase a Beowulf cluster, and start moving their numeric modelers from Sun to Linux.

Congrats!

Like most historically UNIX shops, they don't allow users even low-level SUDO access, to do silly things like change file permissions or ownerships, in a tracked environment. I am an ex-*NIX admin myself ,so I understand their perspective and wish to keep control over the environment, but as a user, I'm frustrated by having to frequently call the help-desk just to get a file ownership changed or a specific package installed.

Good, Good!

If you're an admin, do you allow your users basic SUDO rights like chmod, cp, mv, etc (assuming all SUDO commands are logged to a remote system)?

Hell No!

If no, why don't you?

Because it is my responsibility, and my responsibility alone, to keep those machines running. If you screw up the system, then I will have to work later and possibly come in on the weekend to fix it. This is not something I am willing to risk.

In addition, as an ex-*NIX Administrator, you should know that the best way to keep a secure system is to give the least privs possible.

Makes no sense... (5, Insightful)

boner (27505) | more than 8 years ago | (#14362779)

(Disclosure: I work for Sun and work with Linux since 1994).

Why would you move the modelers to Linux from Solaris? There is no real advantage....
Sure a Beowulf cluster is a nice piece of hardware, but hardware can only compensate a bit for programmer productivity... If their code is written using MPI or OpenMP or some other standard clustering environment then there shouldn't be a need to move the developers, should there? Just recompile and go.
It is really much more efficient to shove faster hardware under a programmer then to force the programmer to adapt to a different programming environment. Programming for a cluster is hard enough without having to take into account the details of the operating system, forcing them from Solaris to Linux might improve the execution part (on a side note, have you considered Sun's clustering tools?). But it *will* set them back in productivity while they move to different compilers and adapt the execution of the program to the Beowulf environment.

In my opinion you have forced your customer to make a move on questionable grounds.

Now to the matter of security. As you are aware, Solaris has the highest level rating for security. Secure Solaris is the defacto operating system at a number of government agencies. Linux cannot hold a candle to the multiple access levels of the Secure Solaris operating system. You state that you are frustrated at needing the helpdesk for file permission changes. What is your point? Are you using the fact that YOU don't like the limitations to change a customer from Solaris to Linux? Or are you complaining that the customer's environment did not deploy secure solaris with its multiple access layers? In Secure Solaris there is no need to muck with sudo. Each file can be managed properly from a security point of view (come to think of it, much of that can be done with Linux too).

Before I answer your question, let me state that I understand your point of view. When I joined the navy as a UNIX project manager, the admins gave me absolutely no rights whatsoever on the production systems. Their reasoning: '.. he can do things I don't understand, can't control or prevent.' There will always be a tension between the lockdown desired by the admins to keep their environment safe and secure and the users who want total freedom....

In my mind there is NO good reason to give ANY user root access in a secure environment. Period. If you have frustrated in the past by having to interface with the helpdesk, then the helpdesk needs to be improved. At the same time, I assume, any user has full access to their files.
You mention that you have convinced modelers to move to a Beowulf environment, then why the issue anyway. If they run cluster code then they run as user. All the need are basic user access rights, nothing more...

Maybe I don't understand your point....

Re:Makes no sense... (2, Insightful)

Large Green Mallard (31462) | more than 8 years ago | (#14362882)

I am glad you did point out at the beginning that you work for Sun, since it does explain your point of view on clustering :) Otherwise it would look entirely crazy.

Beowulf can mean cheap hardware, Sun doesn't. Government doesn't always need secure. He doesn't say what part of the government.. it might be the department of the interior doing climate modelling or something. Trusted/Secure Solaris adds huge amount of overheads to installing and configuring and using a system that they just might not need. Sure, the original poster's view on system administration is somewhat unconventional, but it does seem like they have on-site staff who are more than capable of putting him back in his padded box.

In my opinion you have forced your customer to make a move on questionable grounds .. and in my opinion, you're looking at it from a loosing vendor's point of view, talking about what's bad in this solution.

Not On Your Life (1)

highwaytohell (621667) | more than 8 years ago | (#14362780)

Why you ask? Because i find end users in particular believe their capabilities are such that they could re-write the whole OS, even though they have trouble typing things in a word processor. That, and i dont trust them, people are inquisitive, they like to search around, and inevitably, manage to find a way to screw things up. Giving that sort of access is a bad idea, let alone putting it into practice. That just opens up a Pandora's box of late nights trying to fix the fsck'd system.

Permitted with a clear duty to log actions (2, Interesting)

originalhack (142366) | more than 8 years ago | (#14362786)

I have always had this ability (in several of the largest companies in the US) but I have always started the conversation with an acknowledgment that the sysadmins are ultimately responsible for the network. Then, we focus on what functions I may need to do, how I avoid causing a problem beyond my own work, and how we can establish a regimen where I report what I have touched and where they are able to monitor to ensure that I have do only that.

This has never been a problem. Then again, they already know, prior to that, that they would be in bigger trouble if I were not trustworthy. I offer them more controls than they would have insisted on and this gets me more latitude than they normally would have offerred.

Give them their own systems (3, Insightful)

Anonymous Coward | more than 8 years ago | (#14362788)

I also work for a defense contractor and adhere to strict security rules. We have a fairly simple means of controlling our developers who need root access. We buy their systems using their bosses' overhead or project charge numbers, place them on a monitored, isolated subnet and, when they hose the system, all time expenditures are billed to one of the previously mentioned charge numbers. At my billing rate, it doesn't take too many incidents for them to feel serious heat or be canned. Either way, they do not touch production machines or cause problems that cannot be quickly isolated by disconnecting the subnet.
It works for us.

Doesn't that defeat the point? (2, Informative)

NitsujTPU (19263) | more than 8 years ago | (#14362792)

If you're at a defense contractor, they're probably following the DoD Guidelines of least privelege, logging, stuff of that nature.

What you're asking is, essentially, to establish yourself as a certain class of user under whatever scheme you're using, or for some kind of "well, Slashdot agrees" circumvention of guidelines.

It reminds me of a time that I was working on such a machine, and I sat in a conference room where people were trying to bargain with me as if I represent the STIG. The simple fact of the matter is, the STIG is a set of guidelines, and nobody's opinion will change the contents of the document.

Stop trying to negotiate it.

Re: Got Root? (2, Interesting)

hedrick (701605) | more than 8 years ago | (#14362794)

I work at a University, so we may not be close to your environment to matter. But I would distinguish between production and research systems. I wouldn't give anyone but professional sysadmins anything close to root on systems like mail servers or multiuser systems. But unless you're working with sensitive data, on research systems things are more flexible. A lot depends upon the sophistication of the people involved as well as the actual environment. I'd be more inclined to give out root on a machine with one or two users and I'd be more inclined to give it to somewhat who had sysadmin experience. On a machine shared by a small research group, if I could find one person with reasonable experience, I might try to coopt him into the sysadmin group. That way there's somebody near the users who can solve their problems.

These days security is an issue. But with a compute cluster I'll bet I could come up with a setup where moderate errors wouldn't compromise the rest of the network. A compute cluster is easier because people won't be running browsers on it or reading their email there. That eliminates most of the user-caused problems. So at that point a tight firewall may be enough. On a small research machine used by one research project you're not really trying to protect users from each other. So many of the traditional concerns about protection don't apply.

ACLs? (1)

harlows_monkeys (106428) | more than 8 years ago | (#14362796)

If you use a filesystem and kernel that supports ACLs, users can do everything they should need in almost all circumstances.

There are only a couple of situations I've run into where I've needed more, such as applications that need to bind to a priviledged port, or where I've needed to run a cron job that needed more than 1024 file descriptors and so had to make it setuid root. (Setting the number of file descriptors up for a user via /etc/security/limits.conf doesn't apply to that user's cron jobs).

Switched from Solaris to Linux? Dumb move! (0)

Anonymous Coward | more than 8 years ago | (#14362798)

With Solaris 10 you get so much fine-control over security that you can kick sudo out of the window and use Solaris's built-in tools. Dude, your move to Linux is going to bite you in the arse!

This is where you have multiple environments. (0)

Anonymous Coward | more than 8 years ago | (#14362799)

A sandbox, where the developer can play to his heart's content, doing whatever he wants. He breaks it? He fixes it, or it gets nuked and reinstalled.

A test environment, where every change is logged and monitored. Nothing goes through without being authorised and signed off. The sysadmin is informed of every change, and is allowed to nix a change, for whatever reason; if the developer insists, the sysadmin and the developer sit down to talk about what is being done and why, and why the sysadmin is balking.

A production environment, where every change is logged and monitored. Nothing goes through without having been through test first, nor without the change actually having been tested to a fare thee well.

Allowing any random person the right to chmod, cp, mv, or whatever any files as root is a recipe for massive instability and security problems. Don't do it, unless it's in a sandbox.

Why would you move from Sun Solaris to Linux? (0, Offtopic)

hutchike (837402) | more than 8 years ago | (#14362812)

Solaris seems to be faster than Linux these days, and runs on swanky new Sun Fire T2000 [sun.com] servers. Whether you run Linux or Solaris, file permissions are always an issue. Get used to it.

In defense of sudo (0)

Anonymous Coward | more than 8 years ago | (#14362816)

I'm a Unix Sysadmin (HP-UX, AIX, Tru64, Solaris) who works with a team of Unix admins to handle user requests. I've seen several replies about "not even with sudo access to " but they aren't accurate.

Sudo can be set up to allow a restricted set of commands. Yes it's a pain to give them specific permission to chmod specific directories. Yes it's a pain to set sudo up so that it not only gives fine grained permissions, but also has fine grained denials. This is the power of sudo, and if it's set up properly can be very helpful in reducing some of the work load the admins would be asked to do in a safe manner. Throw logging into the mix, and you can prove WHO ran the command that broke their toy, which is important when someone wants to point fingers. Sudo isn't perfect, and the users shouldn't be given rights to do certain things, but for basic tasks (allow a web developer to reboot the web server on the development box, for instance) it's a blessing.

Chroot them... (1)

Yaa 101 (664725) | more than 8 years ago | (#14362819)

And only give them the tools they really need to develop, test and debug their programs.

Secure != root (0)

Anonymous Coward | more than 8 years ago | (#14362822)

Bottom line is only one single group/user should have full access permissions. Keeping you sandbox is both a blessing and curse. Truat me when I say that the stress level is Much Less when you have only user level access permissions. Enjoy your day and thank the sys. admin when you see him.

fucking fucktards (-1)

Anonymous Coward | more than 8 years ago | (#14362823)

You bunch of linux dick smokers. Fucking fools every one of you. Poking each other up the ass with your fucking linux faggot fantasies.

The legitimate computer world laughs at you shitballs like how normal well adjusted people laugh at faggots.

No more Sun? (1)

St. Arbirix (218306) | more than 8 years ago | (#14362825)

What's wrong with keeping Sun and running Linux on that hardware?

Another question: What's wrong with Solaris?

Developers need more discipline (4, Insightful)

alee (64786) | more than 8 years ago | (#14362826)

I've been both a developer and an administrator.

As a general policy, if a developer needs root access, they need to prove to me as an administrator that they actually do need root access. I'm not going to give root access (sudo, su -, or access to privileged accounts), even on a development box, to someone that needs occasional chmod privileges. More often than not, the people who are begging for root access are those that have been so spoiled by coding on their own Linux boxes that they lose sight of all the best practices that contribute to good code. They want foolish things like directories with 777 privileges so they can drop temp files when there are 30 better ways to do it. root is not a cure all... just because you're used to it on your own machine doesn't mean it's appropriate for coding in a multi-user environment developing customer-facing applications.

In the end, there are very few specialized applications that actually require root access to work. I will concede that sometimes root access is necessary but it needs to be treated on a case-by-case basis. I'm of the belief that a properly written application should be written such that it can be run with the least amount of privileges, and can be installed anywhere... not just /usr. root access as we know it is a luxury that should be reserved for true administrative duties, unless absolutely positively necessary.

accountability and change control (5, Informative)

Yonder Way (603108) | more than 8 years ago | (#14362828)

Another sysadmin who is going to tell you that I don't give out root or sudo access to users. Most users who think they know enough, or even DO know enough, really know enough to make big problems. They invariably never check with me before making a change, or tell me that they made a change, or even admit to having made a change when they inevitably screw something up.

I make them come to me for everything. But not directly. That's what the ticketing system is for. The ticketing system justifies my existence, keeps any requests from slipping through the cracks, and helps to keep track of ad-hoc changes made to any given system.

Many times end users think they need root for something when they don't. For example, there might be some niche tool that they need installed on a system. Or do they? If the one user is the only one that is going to use it, I advise him to do something like "./configure --prefix=~" to build apps to install in his home directory. You don't need root to install apps anymore. Besides, if you want an app installed for everyone to have access to, sysadmin should be doing that anyway.

It might be a pain in the ass to make you go to the sysadmin for everything, but in the long run it will keep things running smoothly and perhaps force you to be a little more disciplined in your work.

chmod (1)

xx_toran_xx (936474) | more than 8 years ago | (#14362837)

If you allow users to chmod, a savvy (enough) user could change permissions on the right stuff (such as the sudoers file) and give himself more access than you may want him to have.

just a thought

Don't install the software as root. (1)

digirus (854991) | more than 8 years ago | (#14362838)

A quote from a text book of mine that I think may help: Some users with unix experience, and particularly those experienced in the linux flavor, may find this caution to be peculiar, in that a conciderable amount of third party software seems to end up installed in privileged system directories these days, as so they might have gotten used to needing to be root to do simple installs. This is the worng way to do things, and fortunately it's a rare unix application that will force you to do things in a poorly thought out fashion if you don't want to. Almost all non-OS-vendor software should be installed and owned by a non-root user. Even vendor supplied copies of third party applications (such as the Apache web server) are best owned and installed by non-root users. This model makes life a slight bit more difficult than just having root own everything, but the benefits far outweight the minor inconveniences. If you conscientiously make certain that everything that's not distinctly part of the OS is owned by a nonprivileged user, you can allow nonprivileged users to modify and maintain those parts of the system with no fear that they are going to do damage to the OS itself. The machine is more secure, the workload of managing software can be distributed, and those users who need to modify configurations (such as the web server settings) can do so without having to annoy root, or run the risk of compromising the system by a careless keystroke while operating as root. Implementing this model will take a small additional amount of effort on your part. You won't be able to follow people's simple-minded instructions to "sudo make install" bits of software. But your machine will be better managed and more secure, and you'll be helping to keep mushy-headed thinking from taking hold of the *NIX platform, if you just take the time to follow these suggestions and set up a nonprivileged software account to own and install the majority of your third party software.

Why the ell not. (0)

Anonymous Coward | more than 8 years ago | (#14362842)

The summary mentions giving users access to commands like chmod, cp etc.

Of course you would give them access to these commands - just in their own little home areas, other areas would be restricted by root permissions.

I see nothing wrong with doing such. If they want to do system level things let them play on a play box.

This is not based on any reality (0)

Anonymous Coward | more than 8 years ago | (#14362846)

This policy keeps IT people employeed, builds IT's fiefdom.

Effects on 'customers' and their productivity is irrelevant, doesn't even cross anyone's minds. These are bureaucracies you are dealing with. Think reptile vs advanced mammal when discussing the differences between bureaucracies and even horrible profit-driven organizations.

I worked for the State of California on a contract about 20 years ago. At that time, the PC was just getting off the ground, but PC-users were forbidden to do anything that could be construed as programming, e.g. spreadsheets and databases. They had "computer police" who came around and inspected computers. Woe unto you if you had forbidden applications. Of course, a lot of people therefore worked from home, did all their databases and spreadsheet work there.

Maybe that policy has changed, but if so, it wasn't because IT decided it was a wise way to enhance the state's productivity. More likely, everyone went along with IT because it increased their budgets.

Lew

root should stick with IT (1)

tolldog (1571) | more than 8 years ago | (#14362847)

If a system is set up correctly, developers should not need root privs. If there are sitiuations to the contrary, then they show a bigger problem with how things are structured or problems with the IT group.

Only IT should be able to modify the base install of a system. This includes common libraries, binaries, directories and other things that are on the system when it is rolled out.

Need to install new commands in a common tree? Have some other directory that is added to a common path that privelaged developers are able to install in.

Need to change file permissions? The only time I have seen this needed was log files that got owned by root after rotation. A better thing would be to make the rotation script give files correct permissions to begin with. A user should not need to change permissions on local files.

Need to install new software? If this is a real server and there is no tracked, established procedure for software being upgraded/installed/removed or altered in some way without IT involvement, there are more serious problems with the structure than the software change. There should always be a procedure that is followed with software changes, that should either be done by or with an IT person.

Servers should rarely be touched. Even desktops should rarely change if you expect some level of support from IT. If the IT group is not giving you the level of support for you to easily do what you need to do, the problem is not the lack of sudo, the problem is the lack of procedures and tracking and all the messy parts of IT that go beyond the root priveledges.

I have had to work on both sides of the sudo/root issue before, and I have seen places where giving root to the wrong person has caused more problems than it has solved. In jobs where I haven't had root, but needed it, there were bigger problems about how software was rolled out and administered. My need for root was a band-aid, quick solution to work around the bigger problem.

I am a firm believer that NFS filesystems should not be mountable without root squash except on a trusted server. If security in your company is important enough to have multiple users and user groups, it is important enough to limit root to those that have to deal with that type of work on a day to day basis.

I can see possibly allowing for one developer in a department to have some level of sudo but only if that person in an IT type support role for the department. (This does not mean somebody who also does IT work because dealing with the IT department is slow and cumbersome.)

sudo to a shell (2)

vivarin (106778) | more than 8 years ago | (#14362848)

We have a special shell for some users that requires they enter what they're doing. They basically do "sudo bashforroot" and have to type in "installing foobarnator" and then they get a root prompt.

Whoah (1)

gringer (252588) | more than 8 years ago | (#14362857)

Imagine a Beowulf cluster of those...

Oh, wait a second. You already have.

Why do they need root? (3, Insightful)

ChaosDiscord (4913) | more than 8 years ago | (#14362864)

Why in the world do your users need root access? On Windows it makes sense; all too many poorly written programs refuse to install or run unless they can run roughshod over the entire system. But this is Unix. It's a rare piece of software that can't be installed and run as a user. Most can even be installed as a user but made available to others. Yeah, it's a bit more frustrating that you can't just install the latest RPM, but if you're skilled enough to install an RPM, you can probably manage "./configure && make --prefix=~/mybin && make install". Changing file ownership? Again, why do you want that? If you're sharing files with other users, get a group set up and chgrp the files appropriately. If you have lots of complex sharing needs, set up one of the Access Control List options.

Ultimately users shouldn't need root. Professionally I development clustering software for Linux and other Unix systems. I regularly install new applications I'd like to use in my home directory. Our administrators set us up with a good ACL system (courtesy of AFS). I do the cast majority of my work as my own account. The only time I need it is to test root-specific aspects of our software (if launched as root, it runs jobs as the user who submitted it). I can't remember the last time I switched to root, probably a month or so ago.

Unless you've got a damn good reason, your administrators are right to withhold root access from you. Your desires aren't good enough.

Most just say no. (2, Insightful)

Liam Slider (908600) | more than 8 years ago | (#14362865)

I say...Hell no. Not on the main system. That's just asking for way too many security problems. These kinds of things are done for a damn good reason. Now...their own desktops, laptops, some isolated and limited test computer, whatever...that's much less of a problem. But letting users have root access, even limited, to the main system is just asking for trouble.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?