3

My service on CentOS is configured to run under a certain user in its config file under /etc/systemd/system:

[Service]
User=buildman

When I am sued as buildman, I can run:

systemctl status myservice.service

but if I try to do start or stop, it prompts me for password.

If I do:

sudo systemctl status myservice.service

it does not prompt me because I have configured visudo:

%buildman ALL= NOPASSWD:  /bin/systemctl * myservice.service

But why doesn't service stop and start work like status? I would like to enable buildman to execute these service commands without sudo or password.

The primary reason for this is that I need to enable service restart from Jenkins and I ran into problems running sudo from its container, which complained that I needed a "TTY" to run it.

dhag
  • 15,440
  • 4
  • 54
  • 65
amphibient
  • 12,222
  • 18
  • 62
  • 87
  • tried sudo /bin/systemctl start myservice (giving full path, like configured in visudo) ? – Tagwint Oct 20 '17 at 17:37
  • your suggestion still requires `sudo` – amphibient Oct 20 '17 at 17:46
  • that's not a suggestion yet :), just a question to figure out some details. Did it work with start / stop too if specifyin full path ? – Tagwint Oct 20 '17 at 17:52
  • Just in case one more check: %buildman denotes a group, not user. Does that group exist?Does user buildman belongs to it? – Tagwint Oct 20 '17 at 18:33
  • yes, that group does exist – amphibient Oct 20 '17 at 18:36
  • Related: [How could we allow non-root users to control a systemd service](https://unix.stackexchange.com/questions/192706/how-could-we-allow-non-root-users-to-control-a-system-d-service) – Mark Plotnick Oct 20 '17 at 18:50
  • Another related question, currently with better more general answers, is https://unix.stackexchange.com/q/496982/5132 . – JdeBP May 01 '20 at 05:18

2 Answers2

1

The difference between start/stop and status is that status does not alter system state.

Any modification of system-wide state or configuration requires system-wide administration privileges -- hence sudo. Reading the 'status' of a service is a read-only operation and so is not normally protected.

It's worth noting that user services do not require sudo. For example

systemctl --user start bobsburgers

will succeed when issued by bob, but only by bob. (Root will not be able to start this service because it is not a root user service.)

So if the service you're interested in here does not alter system-wide state, you could install it as a user service

systemctl --user enable bobsburgers

The standard configuration is to place your service file in ~/.config/systemd/user. As long as the service itself does not require global rights, you should be good to go.

Stephen Boston
  • 1,928
  • 3
  • 25
  • 50
0

status command does not require superuser rights, it works w/o sudo too. start and stop do require sudo. You can avoid entering password but not specifying sudo.

Tagwint
  • 2,410
  • 1
  • 13
  • 22
  • I tried 1 and it didn't work. How do I do your #2 suggestion? – amphibient Oct 20 '17 at 18:12
  • You still need sudo in front of the command for other than status. Assuming sudo config is correct it won't requre password – Tagwint Oct 20 '17 at 18:31
  • this OP asks for a way to do away with sudo – amphibient Oct 20 '17 at 18:36
  • I was wrong about full path guess, sudo config do require full path indeed. sorry, will correct my answer. But I don't think you can avoid sudo for a non-root user. I OP asked 'without sudo OR password' - I suggesed w/o password option – Tagwint Oct 20 '17 at 18:45