-3

I need a tool that would be run by root, drop root by switching to another user, and then execute another program specified by the command line argument(s). Use case: run something from a (custom) init scripts under a non-privileged user.

I want to avoid using su or sudo because they serve a different purpose (provide an interactive way of becoming root for non-privileged users), are much more complex than needed for this task, change behaviour depending on various configuration files, and write stuff to syslog.

Is there such a tool available?

Update: I found an answer buried deep on stackoverflow: it's setuidgid from daemontools (or s6-setuidgid from s6). Apparently, the author(s) of daemontools had some reasons not to use su for running daemons, as well.

The only drawback is that setuidgid remains running along with the program it launched. Ideally I'd prefer it to exec instead of spawn/fork to keep the process table cleaner, but it's not that much of an issue.

Community
  • 1
pvgoran
  • 103
  • 4
  • 4
    With respect, that is *exactly* what `su` is for; as the `man` page says on line one, "*su allows to run commands with a substitute user and group*". It is true that *mostly* it is used for switching to root, but its intended purpose is exactly your usage case. I'm not sure what you mean about it changing behaviour according to config files. – MadHatter Apr 02 '16 at 08:03
  • From man su: "The following configuration variables in /etc/login.defs change the behavior of this tool: ..." - this is what I mean. And it's still complex, unnecessarily interactive, and pollutes syslog. – pvgoran Apr 02 '16 at 08:07
  • 2
    Setting `PATH` is hardly the world's greatest configuration challenge, and in any case, you can override it trivially. I'm not sure what you mean by "*polluting syslog*". I want *everything* in my syslogs, as more data makes for easier forensics *post facto*; why are you trying to minimise what syslog writes? – MadHatter Apr 02 '16 at 10:13
  • @MadHatter The problem with configuration files is unpredictability: now it works, later it doesn't because configuration files changed. As for syslog, this kind of operation (contrary to su's privilege **elevation**) is not much different from any other process invocation. And I don't want to log all process invocations, all file accesses and other trivial operations. – pvgoran Apr 02 '16 at 10:55
  • 1
    Re: configuration, it's only `PATH`, and you shouldn't be relying on `PATH` in *any* non-interactive job; absolute paths should be used at all times. Re: syslog, OK, then configure your syslog not to log it. What goes into syslog, and what comes out of it, are not the same thing. Besides, you may feel that `su` identity change is similar to a file opening, but the designers of your OS clearly didn't, since one syslogs and the other has to be caught via auditd. Consider for a moment that they may have had a reason. – MadHatter Apr 02 '16 at 10:56
  • @MadHatter The su manual lists quite a few variables from login.defs that are said to "change behaviour" of su. IDK, maybe for this use case (switching from root to non-root without login) it's only PATH that matters, but it's hard to tell from the manual. I know that `su` being a setuid program has a very good reason for writing to syslog, and I don't want to lose its logs. But privilege dropping is just a small subset of what `su` can do, and it generally doesn't deserve a syslog entry. – pvgoran Apr 02 '16 at 11:21
  • In my `man` page, they all change `PATH` except the authentication delay one, which doesn't apply to you. As for your thoughts on what does and doesn't deserve syslogging, I urge you to consider that the designers thought otherwise - and you can still filter it out inside syslog, that's what it's for. – MadHatter Apr 02 '16 at 11:27
  • It all boils town to one thing: I need another tool because my task is different from what `su` does in terms of complexity and security implications. Yet you tell me that I should still use `su` and adapt to its complexity and security implications. This doesn't make sense. – pvgoran Apr 02 '16 at 11:54
  • 2
    We get an *awful* lot of questions on here where people are trying to do things the wrong way, and the right response is to point out that they're trying to do them the wrong way, not to help them do so. You've failed to come up with a business reason why you can't use the tool provided, so I'm voting to close. – MadHatter Apr 02 '16 at 12:27
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/37857/discussion-between-pvgoran-and-madhatter). – pvgoran Apr 02 '16 at 13:18
  • 1
    I am not sure why you are so hung-up on _"configuration changes behavior"_ - Most configuration files on your system serves that purpose; it is the point of a conf file... _"now it works, later it doesn't because configuration files change"_ - then do not blindly change conf files.... – pete Apr 02 '16 at 14:11
  • @pete It's fine for a user tool which `su` (in my opinion) is. What I need is a system tool, a building block for system scripts that works reliably and consistently, possibly in systems I don't control. – pvgoran Apr 02 '16 at 16:22

1 Answers1

2

runuser is used for this purpose and its typically ran from init scripts.

Its basically su without the PAM integration.

Matthew Ife
  • 22,927
  • 2
  • 54
  • 71
  • And then there is of course the even more low-level [set-user-ID-on-execution bit](https://en.wikipedia.org/wiki/Setuid) – HBruijn Apr 02 '16 at 08:40
  • I thought runuser was distro-specific for some reason... Anyway, it's much better than su because it's not interactive and only works for root, but it still depends on login.defs and, most importantly, pollutes syslog. (And it doesn't work out of the box on Gentoo, though it's a local problem.) – pvgoran Apr 02 '16 at 08:53
  • @HBruijn Using setuid for this purpose is more a hack than a proper solution, and has unneeded implications. – pvgoran Apr 02 '16 at 08:57
  • 1
    Completely agree that setuid is not a good solution, hence a comment and not a proposed solution and answer – HBruijn Apr 02 '16 at 09:22
  • Just re-read the answer and noticed something. runuser **does** have PAM integration! I wish it didn't, because it's what causes it to write to syslog. – pvgoran Apr 02 '16 at 09:35
  • 1
    @pvgoran Strangly the guy who wrote runuser told me it didn't. But there you go. – Matthew Ife Apr 02 '16 at 12:47
  • @pvgoran As far as I can tell it is distro-specific. There is no `runuser` on Debian or Ubuntu. – kasperd Apr 03 '16 at 15:11
  • @kasperd I have it in Debian stretch/sid (util-linux 2.27.1-1), but not in Ubuntu 14.04.4 LTS (util-linux 2.20.1-5.1ubuntu). Probably depends on how recent the distro release/util-linux package is. – pvgoran Apr 04 '16 at 04:43