10

Is there a way to force to run program as root (with normal user) when there's no sudo on the machine (and can't be added)?

MadBoy
  • 203

1 Answers1

14

Sure: you can set the setuid bit. On a modern system, the simplest command is:

# chmod u+s myprogram

or, if the program is already known to have mode 755:

# chmod 4755 myprogram

This assumes the program is owned by root. You'll need to change the file's owner, too, if it is currently owned by someone else.

Do read that Wikipedia article, particularly the Security section. There's a reason only root can do this to a file, and why few executables on your system have this bit set already.

Warren Young
  • 72,032
  • What about commands like "ulimit -c unlimited" and others? Basically the goal is to give access to some high commands that are used by developers who do testing of the code they created (on the network level) on that Linux machines but they did couple of wrong moves already when being a root user so we want to prevent damage done by them done by accident - like changing root passwords to empty. – MadBoy Jun 17 '13 at 15:00
  • The objective is not to protect the system from compromising, but from screwing it up. Those "linux" are kind of development testing machines. We need to give them ability to do their job without affecting everyone else. – MadBoy Jun 17 '13 at 15:02
  • If the root user has already set a too-low core limit size and you cannot change this, you're pretty much stuffed. They're not likely to let you go setting setuid bits on executables in the first place. If for some reason the site admins you're dealing with are that demented, keep in mind that /usr/bin/ulimit is typically masked by the ulimit shell builtin command. You'll need to specify the path to the program if you want to get its effect as root. – Warren Young Jun 17 '13 at 15:10
  • Thank you. Your help was very appreciated. Hopefully this will be enough. – MadBoy Jun 17 '13 at 15:23
  • @MadBoy: I should also point out that I think simply setting this bit on the ulimit executable is a bad idea. It would mean any user on that system could change their user limits, since they'd be running as root. Plus, the program probably hasn't been audited with setuid in mind. You could modify the scheme a bit, e.g. chmod 4750 /usr/bin/ulimit ; chgrp developers /usr/bin/ulimit, and put all devs needing this more powerful ulimit command in the developers group. Then normal users can't call it, but their needs might be met by the shell builtin. – Warren Young Jun 17 '13 at 15:43
  • Everyone on that machine are developers. That machine's only purposes is to allow developers to test their code. But since they tend to break things by accident and then complain that they lost a day (sic!) because of their actions we want to limit them to just run their tests. Additionally we would like to apply a firewall there so they can connect via SSH and do tests but not go anywhere else (aka transfer code out). So i need to keep iptables/shadow/groups/users protected from them but still allow them to do the work. It's a thin line between being able to deliver solution – MadBoy Jun 17 '13 at 16:32
  • and us protecting code from being transferred out of company. All other machines have firewall's in place (very heavy firewalls without any access to internet or even other machines on the network) but those machines are the only 'weak' links. So far they had root on them but it's time to take that out but still allow them to work. – MadBoy Jun 17 '13 at 16:33
  • I think you ought to give every developer a VM, and rely on copyright law to protect your code instead of shackling your developers. If they screw up their VM, they're a rollback command away from fixing it. – Warren Young Jun 17 '13 at 17:04
  • If that would be that easy ;-) they have some VM's, but they also have some physicals due to ports like COM and others that need to be supported. And copyright law.. well tell that to china, india and others :-) Besides I deal with what I have to. – MadBoy Jun 18 '13 at 10:55