Restarting systemd service only as a specific user?
I created some systemd services which basically works:
location:
/etc/systemd/system/multi-user.target.wants/publicapi.service
content:
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=multi-user.target
When I try to restart the service as techops user in the command line, I get the following output:
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'publicapi.service'.
Multiple identities can be used for authentication:
1. Myself,,, (defaultuser)
2. ,,, (techops)
Choose identity to authenticate as (1-2):
I want that only techops can restart services and I want that this prompt does not appear when being logged in as techops. How can I do that?
I read that there are different approaches with polkit-1 or sudoers, but I'm unsure.
[UPDATE] 2019-01-27 4:40pm
Thanks for this comprehensive answer to Thomas and Perlduck. It helped me to improve my knowledge of systemd.
According to the approach to start the service without a password prompt, and I want to apologize that I did not emphasize the real problem enough:
Actually, what is most important for me is that no other user than techops should stop or start the service. But at least with the first two approaches I can still run service publicapi stop
and I get the prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
again. When I choose the defaultuser and know the password, I could stop all the services. I want to deny this user from doing that, even if he has the password. Important background info to better understand why this is the more important part for me:
The defaultuser is the only user which is exposed to ssh but this user cannot do anything else (except changing to other users if you have the password of these other users). But at the moment, he can start or stop the services, but this user must not to do this.
If someone gets the password of defaultuser and logs in via ssh, then he could stop all the services at the moment. This is what I meant with "I want that only techops can restart services". Sorry, that I was no that exact at my initial question. I thought that sudoing the techops user would maybe bypass this problem, but it does not. The problem itself is not to run the command without password prompt. (I could easily do that as techops user when I just execute /home/techops/publicapi start
). The problem itself is to lock out the defaultuser from starting these services.
And I hoped that any of the solutions could do that.
I started with the approaches of Thomas.
The approach with sudo works when I don't want to get asked for the password for the user techops when I execute the commands as explained, e.g.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
The second approach does not work for me yet. I cannot start the service without password prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
and I stall can login as defaultuser when I have the password of this user.
With the third approach, the service does not even start at boot process anymore so I'm not sure if this approach is the right one for me at all. I cannot even able it with systemctl enable publicapi.service
which leads me to the following error:
Failed to enable unit: Unit file mycuisine-publicapi.service does not exist.
The error does no occur when I move all the services back into /etc/systemd/system/ and execute systemctl enable publicapi.service
. Then the service starts again at boot.
All these approaches will more or less help to bypass the password prompt for the techops user but when I run service publicapi stop
or systemctl stop publicapi
with defaultuser, I can stop the services if I have the password. But my target is to lock out defaultuser from starting or stopping services at all.
systemd sudo access-control polkit
add a comment |
I created some systemd services which basically works:
location:
/etc/systemd/system/multi-user.target.wants/publicapi.service
content:
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=multi-user.target
When I try to restart the service as techops user in the command line, I get the following output:
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'publicapi.service'.
Multiple identities can be used for authentication:
1. Myself,,, (defaultuser)
2. ,,, (techops)
Choose identity to authenticate as (1-2):
I want that only techops can restart services and I want that this prompt does not appear when being logged in as techops. How can I do that?
I read that there are different approaches with polkit-1 or sudoers, but I'm unsure.
[UPDATE] 2019-01-27 4:40pm
Thanks for this comprehensive answer to Thomas and Perlduck. It helped me to improve my knowledge of systemd.
According to the approach to start the service without a password prompt, and I want to apologize that I did not emphasize the real problem enough:
Actually, what is most important for me is that no other user than techops should stop or start the service. But at least with the first two approaches I can still run service publicapi stop
and I get the prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
again. When I choose the defaultuser and know the password, I could stop all the services. I want to deny this user from doing that, even if he has the password. Important background info to better understand why this is the more important part for me:
The defaultuser is the only user which is exposed to ssh but this user cannot do anything else (except changing to other users if you have the password of these other users). But at the moment, he can start or stop the services, but this user must not to do this.
If someone gets the password of defaultuser and logs in via ssh, then he could stop all the services at the moment. This is what I meant with "I want that only techops can restart services". Sorry, that I was no that exact at my initial question. I thought that sudoing the techops user would maybe bypass this problem, but it does not. The problem itself is not to run the command without password prompt. (I could easily do that as techops user when I just execute /home/techops/publicapi start
). The problem itself is to lock out the defaultuser from starting these services.
And I hoped that any of the solutions could do that.
I started with the approaches of Thomas.
The approach with sudo works when I don't want to get asked for the password for the user techops when I execute the commands as explained, e.g.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
The second approach does not work for me yet. I cannot start the service without password prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
and I stall can login as defaultuser when I have the password of this user.
With the third approach, the service does not even start at boot process anymore so I'm not sure if this approach is the right one for me at all. I cannot even able it with systemctl enable publicapi.service
which leads me to the following error:
Failed to enable unit: Unit file mycuisine-publicapi.service does not exist.
The error does no occur when I move all the services back into /etc/systemd/system/ and execute systemctl enable publicapi.service
. Then the service starts again at boot.
All these approaches will more or less help to bypass the password prompt for the techops user but when I run service publicapi stop
or systemctl stop publicapi
with defaultuser, I can stop the services if I have the password. But my target is to lock out defaultuser from starting or stopping services at all.
systemd sudo access-control polkit
1
For the third approach you have to runsystemctl --user ...
as the usertechops
not as root. Neither my suggestion nor the one of @PerlDuck gives anysudo
rights to your defaultuser but only to the techops user.
– Thomas
Jan 27 at 16:12
1
Is the defaultuser configured as sudo? In that case you should remove the user from secondary groups and check your/etc/sudoers
file if there is a reference for that user.
– Thomas
Jan 27 at 16:17
@Thomas Ah, that's it. It works as expected now. Thanks.
– Bevor
Jan 27 at 17:11
add a comment |
I created some systemd services which basically works:
location:
/etc/systemd/system/multi-user.target.wants/publicapi.service
content:
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=multi-user.target
When I try to restart the service as techops user in the command line, I get the following output:
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'publicapi.service'.
Multiple identities can be used for authentication:
1. Myself,,, (defaultuser)
2. ,,, (techops)
Choose identity to authenticate as (1-2):
I want that only techops can restart services and I want that this prompt does not appear when being logged in as techops. How can I do that?
I read that there are different approaches with polkit-1 or sudoers, but I'm unsure.
[UPDATE] 2019-01-27 4:40pm
Thanks for this comprehensive answer to Thomas and Perlduck. It helped me to improve my knowledge of systemd.
According to the approach to start the service without a password prompt, and I want to apologize that I did not emphasize the real problem enough:
Actually, what is most important for me is that no other user than techops should stop or start the service. But at least with the first two approaches I can still run service publicapi stop
and I get the prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
again. When I choose the defaultuser and know the password, I could stop all the services. I want to deny this user from doing that, even if he has the password. Important background info to better understand why this is the more important part for me:
The defaultuser is the only user which is exposed to ssh but this user cannot do anything else (except changing to other users if you have the password of these other users). But at the moment, he can start or stop the services, but this user must not to do this.
If someone gets the password of defaultuser and logs in via ssh, then he could stop all the services at the moment. This is what I meant with "I want that only techops can restart services". Sorry, that I was no that exact at my initial question. I thought that sudoing the techops user would maybe bypass this problem, but it does not. The problem itself is not to run the command without password prompt. (I could easily do that as techops user when I just execute /home/techops/publicapi start
). The problem itself is to lock out the defaultuser from starting these services.
And I hoped that any of the solutions could do that.
I started with the approaches of Thomas.
The approach with sudo works when I don't want to get asked for the password for the user techops when I execute the commands as explained, e.g.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
The second approach does not work for me yet. I cannot start the service without password prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
and I stall can login as defaultuser when I have the password of this user.
With the third approach, the service does not even start at boot process anymore so I'm not sure if this approach is the right one for me at all. I cannot even able it with systemctl enable publicapi.service
which leads me to the following error:
Failed to enable unit: Unit file mycuisine-publicapi.service does not exist.
The error does no occur when I move all the services back into /etc/systemd/system/ and execute systemctl enable publicapi.service
. Then the service starts again at boot.
All these approaches will more or less help to bypass the password prompt for the techops user but when I run service publicapi stop
or systemctl stop publicapi
with defaultuser, I can stop the services if I have the password. But my target is to lock out defaultuser from starting or stopping services at all.
systemd sudo access-control polkit
I created some systemd services which basically works:
location:
/etc/systemd/system/multi-user.target.wants/publicapi.service
content:
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=multi-user.target
When I try to restart the service as techops user in the command line, I get the following output:
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'publicapi.service'.
Multiple identities can be used for authentication:
1. Myself,,, (defaultuser)
2. ,,, (techops)
Choose identity to authenticate as (1-2):
I want that only techops can restart services and I want that this prompt does not appear when being logged in as techops. How can I do that?
I read that there are different approaches with polkit-1 or sudoers, but I'm unsure.
[UPDATE] 2019-01-27 4:40pm
Thanks for this comprehensive answer to Thomas and Perlduck. It helped me to improve my knowledge of systemd.
According to the approach to start the service without a password prompt, and I want to apologize that I did not emphasize the real problem enough:
Actually, what is most important for me is that no other user than techops should stop or start the service. But at least with the first two approaches I can still run service publicapi stop
and I get the prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
again. When I choose the defaultuser and know the password, I could stop all the services. I want to deny this user from doing that, even if he has the password. Important background info to better understand why this is the more important part for me:
The defaultuser is the only user which is exposed to ssh but this user cannot do anything else (except changing to other users if you have the password of these other users). But at the moment, he can start or stop the services, but this user must not to do this.
If someone gets the password of defaultuser and logs in via ssh, then he could stop all the services at the moment. This is what I meant with "I want that only techops can restart services". Sorry, that I was no that exact at my initial question. I thought that sudoing the techops user would maybe bypass this problem, but it does not. The problem itself is not to run the command without password prompt. (I could easily do that as techops user when I just execute /home/techops/publicapi start
). The problem itself is to lock out the defaultuser from starting these services.
And I hoped that any of the solutions could do that.
I started with the approaches of Thomas.
The approach with sudo works when I don't want to get asked for the password for the user techops when I execute the commands as explained, e.g.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
The second approach does not work for me yet. I cannot start the service without password prompt ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
and I stall can login as defaultuser when I have the password of this user.
With the third approach, the service does not even start at boot process anymore so I'm not sure if this approach is the right one for me at all. I cannot even able it with systemctl enable publicapi.service
which leads me to the following error:
Failed to enable unit: Unit file mycuisine-publicapi.service does not exist.
The error does no occur when I move all the services back into /etc/systemd/system/ and execute systemctl enable publicapi.service
. Then the service starts again at boot.
All these approaches will more or less help to bypass the password prompt for the techops user but when I run service publicapi stop
or systemctl stop publicapi
with defaultuser, I can stop the services if I have the password. But my target is to lock out defaultuser from starting or stopping services at all.
systemd sudo access-control polkit
systemd sudo access-control polkit
edited Jan 27 at 15:48
Bevor
asked Jan 27 at 8:45
BevorBevor
2761720
2761720
1
For the third approach you have to runsystemctl --user ...
as the usertechops
not as root. Neither my suggestion nor the one of @PerlDuck gives anysudo
rights to your defaultuser but only to the techops user.
– Thomas
Jan 27 at 16:12
1
Is the defaultuser configured as sudo? In that case you should remove the user from secondary groups and check your/etc/sudoers
file if there is a reference for that user.
– Thomas
Jan 27 at 16:17
@Thomas Ah, that's it. It works as expected now. Thanks.
– Bevor
Jan 27 at 17:11
add a comment |
1
For the third approach you have to runsystemctl --user ...
as the usertechops
not as root. Neither my suggestion nor the one of @PerlDuck gives anysudo
rights to your defaultuser but only to the techops user.
– Thomas
Jan 27 at 16:12
1
Is the defaultuser configured as sudo? In that case you should remove the user from secondary groups and check your/etc/sudoers
file if there is a reference for that user.
– Thomas
Jan 27 at 16:17
@Thomas Ah, that's it. It works as expected now. Thanks.
– Bevor
Jan 27 at 17:11
1
1
For the third approach you have to run
systemctl --user ...
as the user techops
not as root. Neither my suggestion nor the one of @PerlDuck gives any sudo
rights to your defaultuser but only to the techops user.– Thomas
Jan 27 at 16:12
For the third approach you have to run
systemctl --user ...
as the user techops
not as root. Neither my suggestion nor the one of @PerlDuck gives any sudo
rights to your defaultuser but only to the techops user.– Thomas
Jan 27 at 16:12
1
1
Is the defaultuser configured as sudo? In that case you should remove the user from secondary groups and check your
/etc/sudoers
file if there is a reference for that user.– Thomas
Jan 27 at 16:17
Is the defaultuser configured as sudo? In that case you should remove the user from secondary groups and check your
/etc/sudoers
file if there is a reference for that user.– Thomas
Jan 27 at 16:17
@Thomas Ah, that's it. It works as expected now. Thanks.
– Bevor
Jan 27 at 17:11
@Thomas Ah, that's it. It works as expected now. Thanks.
– Bevor
Jan 27 at 17:11
add a comment |
2 Answers
2
active
oldest
votes
To achieve that the user techops
can control the service publicapi.service
without giving a password, you have different possiblities. Which one is suitable for you cannot be answered as you have to choose on your own.
The classical sudo
approach is maybe the most used, as it is there for a long time. You would have to create e.g. the file as follows.
Note that the drop-in directory /etc/sudoers.d
is only active when #includedir /etc/sudoers.d
is set in /etc/sudoers
. But that should be the case if you are using a modern Ubuntu distribution. As root
execute:
cat > /etc/sudoers.d/techops << SUDO
techops ALL= NOPASSWD: /bin/systemctl restart publicapi.service
techops ALL= NOPASSWD: /bin/systemctl stop publicapi.service
techops ALL= NOPASSWD: /bin/systemctl start publicapi.service
SUDO
Now you should be able to run the systemctl
commands as user techops
without giving a password by prepending sudo
to the commands.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
sudo systemctl restart publicapi.service
The second method would be to use PolKit (was renamed from PolicyKit) to allow the user techops
to control systemd
services. Depending on the version of polit
, you can give normal users control over systemd units.
To check the polkit version, just run pkaction --version
.
with polkit version 0.106 and higher, you can allow users to control specific systemd units.
To do so, you could create a rule asroot
:
cat > /etc/polkit-1/rules.d/10-techops.rules << POLKIT
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "publicapi.service" &&
subject.user == "techops") {
return polkit.Result.YES;
}
});
POLKIT
with polkit version 0.105 and lower: you can allow users to control systemd units. This unfortunately includes all systemd units and you might not want to do this. Not sure if there is a way to limit access to specific systemd units with version 0.105 or lower, but maybe someone else can clarify.
To enable this, you could create a file asroot
:
cat > /etc/polkit-1/localauthority/50-local.d/org.freedesktop.systemd1.pkla << POLKIT
[Allow user techops to run systemctl commands]
Identity=unix-user:techops
Action=org.freedesktop.systemd1.manage-units
ResultInactive=no
ResultActive=no
ResultAny=yes
POLKIT
In both cases you can run systemctl [start|stop|restart] publicapi.service
as user techops
without giving a password. In the latter case ( polkit <= 0.105 ) the user techops
could control any systemd unit.
A third option would be to make the service a user service, which does not need sudo
or polkit
configurations. This puts everything under the control of the user and only works if your actual service that is started with /home/techops/publicapi start
can run without root
privileges.
First you have to enable lingering for the user techops
. This is needed to startup the user service on boot. As root
execute:
loginctl enable-linger techops
Next you have to move the systemd
unit file into the techops
user directory. As user techops
execute the commands as follows.
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/publicapi.service << UNIT
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=default.target
UNIT
Note that the WantedBy
has to be default.target
as there is no multi-user.target
in the user context.
Now reload the configuration and enable the service. Again as user techops
execute the commands.
systemctl --user daemon-reload
systemctl --user enable publicapi.service
systemctl --user start publicapi.service
In general you should place your systemd units in /etc/systemd/system/
not directly in /etc/systemd/system/multi-user.target.wants
. When you execute systemctl enable publicapi.service
a symbolic link will be created in etc/systemd/system/multi-user.target.wants
or whatever target is specified for that unit.
As already mentioned, if the service/process itself can be run without root privileges you should consider adding User=techops
to your unit file to run the process with a non-privileged user account.
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Sorry, for the.pkla
not working. This needs a[section]
entry. Updated answer.
– Thomas
Jan 27 at 16:04
add a comment |
First of all, you don't put a unit file in the directory
/etc/systemd/system/multi-user.target.wants
. This directory is
maintained by systemd
and the systemctl
commands.
Put the unit file in /etc/systemd/system
instead and then
enable it with
sudo systemctl enable publicapi.service
This will create a symlink below multi-user.target.wants
(or wherever,
systemctl
knows better) to honor the lines
[Install]
WantedBy=multi-user.target
in the unit.
Next, create a sudoers
file below /etc/sudoers.d
:
sudo visudo -f /etc/sudoers.d/techops
with the following content:
Cmnd_Alias HANDLE_PUBLICAPI =
/bin/systemctl start publicapi.service
/bin/systemctl stop publicapi.service
/bin/systemctl restart publicapi.service
techops ALL = (root) NOPASSWD: HANDLE_PUBLICAPI
Do not use a regular editor (e.g. sudo vim /etc/sudoers.d/techops
)
to edit that file because if you put any syntax errors in it you won't
be able to run sudo
again. visudo
on the other hand checks the
syntax of the file before leaving the editor.
Now the user techops
can run
sudo systemctl start publicapi.service
and the other two without supplying a password. Note that you must type
the command and parameters exactly as given in the sudoers
file (except for
the /bin/systemctl
part which can be shortened to just systemctl
).
For instance, sudo /bin/systemctl start publicapi
(whithout .service
)
would ask for a password.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496982%2frestarting-systemd-service-only-as-a-specific-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
To achieve that the user techops
can control the service publicapi.service
without giving a password, you have different possiblities. Which one is suitable for you cannot be answered as you have to choose on your own.
The classical sudo
approach is maybe the most used, as it is there for a long time. You would have to create e.g. the file as follows.
Note that the drop-in directory /etc/sudoers.d
is only active when #includedir /etc/sudoers.d
is set in /etc/sudoers
. But that should be the case if you are using a modern Ubuntu distribution. As root
execute:
cat > /etc/sudoers.d/techops << SUDO
techops ALL= NOPASSWD: /bin/systemctl restart publicapi.service
techops ALL= NOPASSWD: /bin/systemctl stop publicapi.service
techops ALL= NOPASSWD: /bin/systemctl start publicapi.service
SUDO
Now you should be able to run the systemctl
commands as user techops
without giving a password by prepending sudo
to the commands.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
sudo systemctl restart publicapi.service
The second method would be to use PolKit (was renamed from PolicyKit) to allow the user techops
to control systemd
services. Depending on the version of polit
, you can give normal users control over systemd units.
To check the polkit version, just run pkaction --version
.
with polkit version 0.106 and higher, you can allow users to control specific systemd units.
To do so, you could create a rule asroot
:
cat > /etc/polkit-1/rules.d/10-techops.rules << POLKIT
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "publicapi.service" &&
subject.user == "techops") {
return polkit.Result.YES;
}
});
POLKIT
with polkit version 0.105 and lower: you can allow users to control systemd units. This unfortunately includes all systemd units and you might not want to do this. Not sure if there is a way to limit access to specific systemd units with version 0.105 or lower, but maybe someone else can clarify.
To enable this, you could create a file asroot
:
cat > /etc/polkit-1/localauthority/50-local.d/org.freedesktop.systemd1.pkla << POLKIT
[Allow user techops to run systemctl commands]
Identity=unix-user:techops
Action=org.freedesktop.systemd1.manage-units
ResultInactive=no
ResultActive=no
ResultAny=yes
POLKIT
In both cases you can run systemctl [start|stop|restart] publicapi.service
as user techops
without giving a password. In the latter case ( polkit <= 0.105 ) the user techops
could control any systemd unit.
A third option would be to make the service a user service, which does not need sudo
or polkit
configurations. This puts everything under the control of the user and only works if your actual service that is started with /home/techops/publicapi start
can run without root
privileges.
First you have to enable lingering for the user techops
. This is needed to startup the user service on boot. As root
execute:
loginctl enable-linger techops
Next you have to move the systemd
unit file into the techops
user directory. As user techops
execute the commands as follows.
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/publicapi.service << UNIT
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=default.target
UNIT
Note that the WantedBy
has to be default.target
as there is no multi-user.target
in the user context.
Now reload the configuration and enable the service. Again as user techops
execute the commands.
systemctl --user daemon-reload
systemctl --user enable publicapi.service
systemctl --user start publicapi.service
In general you should place your systemd units in /etc/systemd/system/
not directly in /etc/systemd/system/multi-user.target.wants
. When you execute systemctl enable publicapi.service
a symbolic link will be created in etc/systemd/system/multi-user.target.wants
or whatever target is specified for that unit.
As already mentioned, if the service/process itself can be run without root privileges you should consider adding User=techops
to your unit file to run the process with a non-privileged user account.
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Sorry, for the.pkla
not working. This needs a[section]
entry. Updated answer.
– Thomas
Jan 27 at 16:04
add a comment |
To achieve that the user techops
can control the service publicapi.service
without giving a password, you have different possiblities. Which one is suitable for you cannot be answered as you have to choose on your own.
The classical sudo
approach is maybe the most used, as it is there for a long time. You would have to create e.g. the file as follows.
Note that the drop-in directory /etc/sudoers.d
is only active when #includedir /etc/sudoers.d
is set in /etc/sudoers
. But that should be the case if you are using a modern Ubuntu distribution. As root
execute:
cat > /etc/sudoers.d/techops << SUDO
techops ALL= NOPASSWD: /bin/systemctl restart publicapi.service
techops ALL= NOPASSWD: /bin/systemctl stop publicapi.service
techops ALL= NOPASSWD: /bin/systemctl start publicapi.service
SUDO
Now you should be able to run the systemctl
commands as user techops
without giving a password by prepending sudo
to the commands.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
sudo systemctl restart publicapi.service
The second method would be to use PolKit (was renamed from PolicyKit) to allow the user techops
to control systemd
services. Depending on the version of polit
, you can give normal users control over systemd units.
To check the polkit version, just run pkaction --version
.
with polkit version 0.106 and higher, you can allow users to control specific systemd units.
To do so, you could create a rule asroot
:
cat > /etc/polkit-1/rules.d/10-techops.rules << POLKIT
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "publicapi.service" &&
subject.user == "techops") {
return polkit.Result.YES;
}
});
POLKIT
with polkit version 0.105 and lower: you can allow users to control systemd units. This unfortunately includes all systemd units and you might not want to do this. Not sure if there is a way to limit access to specific systemd units with version 0.105 or lower, but maybe someone else can clarify.
To enable this, you could create a file asroot
:
cat > /etc/polkit-1/localauthority/50-local.d/org.freedesktop.systemd1.pkla << POLKIT
[Allow user techops to run systemctl commands]
Identity=unix-user:techops
Action=org.freedesktop.systemd1.manage-units
ResultInactive=no
ResultActive=no
ResultAny=yes
POLKIT
In both cases you can run systemctl [start|stop|restart] publicapi.service
as user techops
without giving a password. In the latter case ( polkit <= 0.105 ) the user techops
could control any systemd unit.
A third option would be to make the service a user service, which does not need sudo
or polkit
configurations. This puts everything under the control of the user and only works if your actual service that is started with /home/techops/publicapi start
can run without root
privileges.
First you have to enable lingering for the user techops
. This is needed to startup the user service on boot. As root
execute:
loginctl enable-linger techops
Next you have to move the systemd
unit file into the techops
user directory. As user techops
execute the commands as follows.
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/publicapi.service << UNIT
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=default.target
UNIT
Note that the WantedBy
has to be default.target
as there is no multi-user.target
in the user context.
Now reload the configuration and enable the service. Again as user techops
execute the commands.
systemctl --user daemon-reload
systemctl --user enable publicapi.service
systemctl --user start publicapi.service
In general you should place your systemd units in /etc/systemd/system/
not directly in /etc/systemd/system/multi-user.target.wants
. When you execute systemctl enable publicapi.service
a symbolic link will be created in etc/systemd/system/multi-user.target.wants
or whatever target is specified for that unit.
As already mentioned, if the service/process itself can be run without root privileges you should consider adding User=techops
to your unit file to run the process with a non-privileged user account.
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Sorry, for the.pkla
not working. This needs a[section]
entry. Updated answer.
– Thomas
Jan 27 at 16:04
add a comment |
To achieve that the user techops
can control the service publicapi.service
without giving a password, you have different possiblities. Which one is suitable for you cannot be answered as you have to choose on your own.
The classical sudo
approach is maybe the most used, as it is there for a long time. You would have to create e.g. the file as follows.
Note that the drop-in directory /etc/sudoers.d
is only active when #includedir /etc/sudoers.d
is set in /etc/sudoers
. But that should be the case if you are using a modern Ubuntu distribution. As root
execute:
cat > /etc/sudoers.d/techops << SUDO
techops ALL= NOPASSWD: /bin/systemctl restart publicapi.service
techops ALL= NOPASSWD: /bin/systemctl stop publicapi.service
techops ALL= NOPASSWD: /bin/systemctl start publicapi.service
SUDO
Now you should be able to run the systemctl
commands as user techops
without giving a password by prepending sudo
to the commands.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
sudo systemctl restart publicapi.service
The second method would be to use PolKit (was renamed from PolicyKit) to allow the user techops
to control systemd
services. Depending on the version of polit
, you can give normal users control over systemd units.
To check the polkit version, just run pkaction --version
.
with polkit version 0.106 and higher, you can allow users to control specific systemd units.
To do so, you could create a rule asroot
:
cat > /etc/polkit-1/rules.d/10-techops.rules << POLKIT
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "publicapi.service" &&
subject.user == "techops") {
return polkit.Result.YES;
}
});
POLKIT
with polkit version 0.105 and lower: you can allow users to control systemd units. This unfortunately includes all systemd units and you might not want to do this. Not sure if there is a way to limit access to specific systemd units with version 0.105 or lower, but maybe someone else can clarify.
To enable this, you could create a file asroot
:
cat > /etc/polkit-1/localauthority/50-local.d/org.freedesktop.systemd1.pkla << POLKIT
[Allow user techops to run systemctl commands]
Identity=unix-user:techops
Action=org.freedesktop.systemd1.manage-units
ResultInactive=no
ResultActive=no
ResultAny=yes
POLKIT
In both cases you can run systemctl [start|stop|restart] publicapi.service
as user techops
without giving a password. In the latter case ( polkit <= 0.105 ) the user techops
could control any systemd unit.
A third option would be to make the service a user service, which does not need sudo
or polkit
configurations. This puts everything under the control of the user and only works if your actual service that is started with /home/techops/publicapi start
can run without root
privileges.
First you have to enable lingering for the user techops
. This is needed to startup the user service on boot. As root
execute:
loginctl enable-linger techops
Next you have to move the systemd
unit file into the techops
user directory. As user techops
execute the commands as follows.
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/publicapi.service << UNIT
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=default.target
UNIT
Note that the WantedBy
has to be default.target
as there is no multi-user.target
in the user context.
Now reload the configuration and enable the service. Again as user techops
execute the commands.
systemctl --user daemon-reload
systemctl --user enable publicapi.service
systemctl --user start publicapi.service
In general you should place your systemd units in /etc/systemd/system/
not directly in /etc/systemd/system/multi-user.target.wants
. When you execute systemctl enable publicapi.service
a symbolic link will be created in etc/systemd/system/multi-user.target.wants
or whatever target is specified for that unit.
As already mentioned, if the service/process itself can be run without root privileges you should consider adding User=techops
to your unit file to run the process with a non-privileged user account.
To achieve that the user techops
can control the service publicapi.service
without giving a password, you have different possiblities. Which one is suitable for you cannot be answered as you have to choose on your own.
The classical sudo
approach is maybe the most used, as it is there for a long time. You would have to create e.g. the file as follows.
Note that the drop-in directory /etc/sudoers.d
is only active when #includedir /etc/sudoers.d
is set in /etc/sudoers
. But that should be the case if you are using a modern Ubuntu distribution. As root
execute:
cat > /etc/sudoers.d/techops << SUDO
techops ALL= NOPASSWD: /bin/systemctl restart publicapi.service
techops ALL= NOPASSWD: /bin/systemctl stop publicapi.service
techops ALL= NOPASSWD: /bin/systemctl start publicapi.service
SUDO
Now you should be able to run the systemctl
commands as user techops
without giving a password by prepending sudo
to the commands.
sudo systemctl start publicapi.service
sudo systemctl stop publicapi.service
sudo systemctl restart publicapi.service
The second method would be to use PolKit (was renamed from PolicyKit) to allow the user techops
to control systemd
services. Depending on the version of polit
, you can give normal users control over systemd units.
To check the polkit version, just run pkaction --version
.
with polkit version 0.106 and higher, you can allow users to control specific systemd units.
To do so, you could create a rule asroot
:
cat > /etc/polkit-1/rules.d/10-techops.rules << POLKIT
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "publicapi.service" &&
subject.user == "techops") {
return polkit.Result.YES;
}
});
POLKIT
with polkit version 0.105 and lower: you can allow users to control systemd units. This unfortunately includes all systemd units and you might not want to do this. Not sure if there is a way to limit access to specific systemd units with version 0.105 or lower, but maybe someone else can clarify.
To enable this, you could create a file asroot
:
cat > /etc/polkit-1/localauthority/50-local.d/org.freedesktop.systemd1.pkla << POLKIT
[Allow user techops to run systemctl commands]
Identity=unix-user:techops
Action=org.freedesktop.systemd1.manage-units
ResultInactive=no
ResultActive=no
ResultAny=yes
POLKIT
In both cases you can run systemctl [start|stop|restart] publicapi.service
as user techops
without giving a password. In the latter case ( polkit <= 0.105 ) the user techops
could control any systemd unit.
A third option would be to make the service a user service, which does not need sudo
or polkit
configurations. This puts everything under the control of the user and only works if your actual service that is started with /home/techops/publicapi start
can run without root
privileges.
First you have to enable lingering for the user techops
. This is needed to startup the user service on boot. As root
execute:
loginctl enable-linger techops
Next you have to move the systemd
unit file into the techops
user directory. As user techops
execute the commands as follows.
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/publicapi.service << UNIT
[Unit]
Description=public api startup script
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/publicapi start
ExecStop=/home/techops/publicapi stop
[Install]
WantedBy=default.target
UNIT
Note that the WantedBy
has to be default.target
as there is no multi-user.target
in the user context.
Now reload the configuration and enable the service. Again as user techops
execute the commands.
systemctl --user daemon-reload
systemctl --user enable publicapi.service
systemctl --user start publicapi.service
In general you should place your systemd units in /etc/systemd/system/
not directly in /etc/systemd/system/multi-user.target.wants
. When you execute systemctl enable publicapi.service
a symbolic link will be created in etc/systemd/system/multi-user.target.wants
or whatever target is specified for that unit.
As already mentioned, if the service/process itself can be run without root privileges you should consider adding User=techops
to your unit file to run the process with a non-privileged user account.
edited Jan 27 at 16:09
answered Jan 27 at 13:03
ThomasThomas
3,94161327
3,94161327
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Sorry, for the.pkla
not working. This needs a[section]
entry. Updated answer.
– Thomas
Jan 27 at 16:04
add a comment |
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Sorry, for the.pkla
not working. This needs a[section]
entry. Updated answer.
– Thomas
Jan 27 at 16:04
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Very good. You even thought of the different WantedBy target for user units. Obviously, this is not the first unit file you wrote :-)
– PerlDuck
Jan 27 at 13:26
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Tanks @PerlDuck. =0)
– Thomas
Jan 27 at 13:33
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Thanks for your reply. This partly answers my question, but I still have my initial problem. (I updated the question)
– Bevor
Jan 27 at 15:50
Sorry, for the
.pkla
not working. This needs a [section]
entry. Updated answer.– Thomas
Jan 27 at 16:04
Sorry, for the
.pkla
not working. This needs a [section]
entry. Updated answer.– Thomas
Jan 27 at 16:04
add a comment |
First of all, you don't put a unit file in the directory
/etc/systemd/system/multi-user.target.wants
. This directory is
maintained by systemd
and the systemctl
commands.
Put the unit file in /etc/systemd/system
instead and then
enable it with
sudo systemctl enable publicapi.service
This will create a symlink below multi-user.target.wants
(or wherever,
systemctl
knows better) to honor the lines
[Install]
WantedBy=multi-user.target
in the unit.
Next, create a sudoers
file below /etc/sudoers.d
:
sudo visudo -f /etc/sudoers.d/techops
with the following content:
Cmnd_Alias HANDLE_PUBLICAPI =
/bin/systemctl start publicapi.service
/bin/systemctl stop publicapi.service
/bin/systemctl restart publicapi.service
techops ALL = (root) NOPASSWD: HANDLE_PUBLICAPI
Do not use a regular editor (e.g. sudo vim /etc/sudoers.d/techops
)
to edit that file because if you put any syntax errors in it you won't
be able to run sudo
again. visudo
on the other hand checks the
syntax of the file before leaving the editor.
Now the user techops
can run
sudo systemctl start publicapi.service
and the other two without supplying a password. Note that you must type
the command and parameters exactly as given in the sudoers
file (except for
the /bin/systemctl
part which can be shortened to just systemctl
).
For instance, sudo /bin/systemctl start publicapi
(whithout .service
)
would ask for a password.
add a comment |
First of all, you don't put a unit file in the directory
/etc/systemd/system/multi-user.target.wants
. This directory is
maintained by systemd
and the systemctl
commands.
Put the unit file in /etc/systemd/system
instead and then
enable it with
sudo systemctl enable publicapi.service
This will create a symlink below multi-user.target.wants
(or wherever,
systemctl
knows better) to honor the lines
[Install]
WantedBy=multi-user.target
in the unit.
Next, create a sudoers
file below /etc/sudoers.d
:
sudo visudo -f /etc/sudoers.d/techops
with the following content:
Cmnd_Alias HANDLE_PUBLICAPI =
/bin/systemctl start publicapi.service
/bin/systemctl stop publicapi.service
/bin/systemctl restart publicapi.service
techops ALL = (root) NOPASSWD: HANDLE_PUBLICAPI
Do not use a regular editor (e.g. sudo vim /etc/sudoers.d/techops
)
to edit that file because if you put any syntax errors in it you won't
be able to run sudo
again. visudo
on the other hand checks the
syntax of the file before leaving the editor.
Now the user techops
can run
sudo systemctl start publicapi.service
and the other two without supplying a password. Note that you must type
the command and parameters exactly as given in the sudoers
file (except for
the /bin/systemctl
part which can be shortened to just systemctl
).
For instance, sudo /bin/systemctl start publicapi
(whithout .service
)
would ask for a password.
add a comment |
First of all, you don't put a unit file in the directory
/etc/systemd/system/multi-user.target.wants
. This directory is
maintained by systemd
and the systemctl
commands.
Put the unit file in /etc/systemd/system
instead and then
enable it with
sudo systemctl enable publicapi.service
This will create a symlink below multi-user.target.wants
(or wherever,
systemctl
knows better) to honor the lines
[Install]
WantedBy=multi-user.target
in the unit.
Next, create a sudoers
file below /etc/sudoers.d
:
sudo visudo -f /etc/sudoers.d/techops
with the following content:
Cmnd_Alias HANDLE_PUBLICAPI =
/bin/systemctl start publicapi.service
/bin/systemctl stop publicapi.service
/bin/systemctl restart publicapi.service
techops ALL = (root) NOPASSWD: HANDLE_PUBLICAPI
Do not use a regular editor (e.g. sudo vim /etc/sudoers.d/techops
)
to edit that file because if you put any syntax errors in it you won't
be able to run sudo
again. visudo
on the other hand checks the
syntax of the file before leaving the editor.
Now the user techops
can run
sudo systemctl start publicapi.service
and the other two without supplying a password. Note that you must type
the command and parameters exactly as given in the sudoers
file (except for
the /bin/systemctl
part which can be shortened to just systemctl
).
For instance, sudo /bin/systemctl start publicapi
(whithout .service
)
would ask for a password.
First of all, you don't put a unit file in the directory
/etc/systemd/system/multi-user.target.wants
. This directory is
maintained by systemd
and the systemctl
commands.
Put the unit file in /etc/systemd/system
instead and then
enable it with
sudo systemctl enable publicapi.service
This will create a symlink below multi-user.target.wants
(or wherever,
systemctl
knows better) to honor the lines
[Install]
WantedBy=multi-user.target
in the unit.
Next, create a sudoers
file below /etc/sudoers.d
:
sudo visudo -f /etc/sudoers.d/techops
with the following content:
Cmnd_Alias HANDLE_PUBLICAPI =
/bin/systemctl start publicapi.service
/bin/systemctl stop publicapi.service
/bin/systemctl restart publicapi.service
techops ALL = (root) NOPASSWD: HANDLE_PUBLICAPI
Do not use a regular editor (e.g. sudo vim /etc/sudoers.d/techops
)
to edit that file because if you put any syntax errors in it you won't
be able to run sudo
again. visudo
on the other hand checks the
syntax of the file before leaving the editor.
Now the user techops
can run
sudo systemctl start publicapi.service
and the other two without supplying a password. Note that you must type
the command and parameters exactly as given in the sudoers
file (except for
the /bin/systemctl
part which can be shortened to just systemctl
).
For instance, sudo /bin/systemctl start publicapi
(whithout .service
)
would ask for a password.
answered Jan 27 at 12:54
PerlDuckPerlDuck
1788
1788
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496982%2frestarting-systemd-service-only-as-a-specific-user%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
For the third approach you have to run
systemctl --user ...
as the usertechops
not as root. Neither my suggestion nor the one of @PerlDuck gives anysudo
rights to your defaultuser but only to the techops user.– Thomas
Jan 27 at 16:12
1
Is the defaultuser configured as sudo? In that case you should remove the user from secondary groups and check your
/etc/sudoers
file if there is a reference for that user.– Thomas
Jan 27 at 16:17
@Thomas Ah, that's it. It works as expected now. Thanks.
– Bevor
Jan 27 at 17:11