Is setcap deprecated?
Clash Royale CLAN TAG#URR8PPP
I'm starting a webserver as non-root using a systemd unit file.
I am getting listen tcp :80: bind: permission denied even though I already ran
setcap cap_net_bind_service=+ep
on the executable.
In an example unit file on the internet I found
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
to be used in the unit file. So I tried that out, and suddenly the application can bind port 80.
What does that tell me? setcap is old/deprecated/ignored? Only by systemd or by Linux in general?
systemd capabilities setcap
asked Dec 14 at 22:53
AndreKR
356420
add a comment |
I'm starting a webserver as non-root using a systemd unit file.
I am getting listen tcp :80: bind: permission denied even though I already ran
setcap cap_net_bind_service=+ep
on the executable.
In an example unit file on the internet I found
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
to be used in the unit file. So I tried that out, and suddenly the application can bind port 80.
What does that tell me? setcap is old/deprecated/ignored? Only by systemd or by Linux in general?
systemd capabilities setcap
asked Dec 14 at 22:53
AndreKR
356420
setcapworks as if you were setting the SETUID bit on the file, that means that a regular use would gain the extra capabilities listed there, that can be necessary but not when starting a daemon
– Bigon
Dec 15 at 9:52
add a comment |
I'm starting a webserver as non-root using a systemd unit file.
I am getting listen tcp :80: bind: permission denied even though I already ran
setcap cap_net_bind_service=+ep
on the executable.
In an example unit file on the internet I found
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
to be used in the unit file. So I tried that out, and suddenly the application can bind port 80.
What does that tell me? setcap is old/deprecated/ignored? Only by systemd or by Linux in general?
systemd capabilities setcap
asked Dec 14 at 22:53
AndreKR
356420
I'm starting a webserver as non-root using a systemd unit file.
I am getting listen tcp :80: bind: permission denied even though I already ran
setcap cap_net_bind_service=+ep
on the executable.
In an example unit file on the internet I found
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
to be used in the unit file. So I tried that out, and suddenly the application can bind port 80.
What does that tell me? setcap is old/deprecated/ignored? Only by systemd or by Linux in general?
systemd capabilities setcap
systemd capabilities setcap
asked Dec 14 at 22:53
AndreKR
356420
asked Dec 14 at 22:53
AndreKR
356420
asked Dec 14 at 22:53
AndreKR
356420
asked Dec 14 at 22:53
AndreKR
356420
asked Dec 14 at 22:53
AndreKR
356420
356420
setcapworks as if you were setting the SETUID bit on the file, that means that a regular use would gain the extra capabilities listed there, that can be necessary but not when starting a daemon
– Bigon
Dec 15 at 9:52
add a comment |
setcapworks as if you were setting the SETUID bit on the file, that means that a regular use would gain the extra capabilities listed there, that can be necessary but not when starting a daemon
– Bigon
Dec 15 at 9:52
setcapworks as if you were setting the SETUID bit on the file, that means that a regular use would gain the extra capabilities listed there, that can be necessary but not when starting a daemon– Bigon
Dec 15 at 9:52
setcapworks as if you were setting the SETUID bit on the file, that means that a regular use would gain the extra capabilities listed there, that can be necessary but not when starting a daemon– Bigon
Dec 15 at 9:52
add a comment |
1 Answer
1
active
oldest
votes
It's correct to say that in general systemd will not work with file capabilities managed with setcap and will require you to configure them as part of the service unit instead.
So it's not like setcap is completely deprecated... (There might be valid uses for it outside of services launched by systemd.) But it doesn't really work for systemd services, at least.
In fact, file capabilities (set by setcap) were always dubious and questionable, from the start... They require the use of "inheritable" capabilities, which were somewhat poorly conceived and had many shortcomings... The kernel feature of "ambient" capabilities was introduced to solve many of these issues and it's what newer systems are adopting (systemd included here, as you can see, you're setting AmbientCapabilities= for your service to manage to be able to bind to low ports.)
The topic of capabilities is fairly complex... For a perhaps gentler introduction to this issue, you might want to check "Inheriting capabilities" at LWN. For the full gory details (including some algebraic notation on the capability sets), refer to the capabilities(7) man page.
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
1
Why?CapabilityBoundingSet=: "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."
– sourcejedi
Dec 14 at 23:23
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is thatSecureBits=lackskeep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)
– Filipe Brandenburger
Dec 14 at 23:41
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%2f488075%2fis-setcap-deprecated%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's correct to say that in general systemd will not work with file capabilities managed with setcap and will require you to configure them as part of the service unit instead.
So it's not like setcap is completely deprecated... (There might be valid uses for it outside of services launched by systemd.) But it doesn't really work for systemd services, at least.
In fact, file capabilities (set by setcap) were always dubious and questionable, from the start... They require the use of "inheritable" capabilities, which were somewhat poorly conceived and had many shortcomings... The kernel feature of "ambient" capabilities was introduced to solve many of these issues and it's what newer systems are adopting (systemd included here, as you can see, you're setting AmbientCapabilities= for your service to manage to be able to bind to low ports.)
The topic of capabilities is fairly complex... For a perhaps gentler introduction to this issue, you might want to check "Inheriting capabilities" at LWN. For the full gory details (including some algebraic notation on the capability sets), refer to the capabilities(7) man page.
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
1
Why?CapabilityBoundingSet=: "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."
– sourcejedi
Dec 14 at 23:23
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is thatSecureBits=lackskeep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)
– Filipe Brandenburger
Dec 14 at 23:41
add a comment |
It's correct to say that in general systemd will not work with file capabilities managed with setcap and will require you to configure them as part of the service unit instead.
So it's not like setcap is completely deprecated... (There might be valid uses for it outside of services launched by systemd.) But it doesn't really work for systemd services, at least.
In fact, file capabilities (set by setcap) were always dubious and questionable, from the start... They require the use of "inheritable" capabilities, which were somewhat poorly conceived and had many shortcomings... The kernel feature of "ambient" capabilities was introduced to solve many of these issues and it's what newer systems are adopting (systemd included here, as you can see, you're setting AmbientCapabilities= for your service to manage to be able to bind to low ports.)
The topic of capabilities is fairly complex... For a perhaps gentler introduction to this issue, you might want to check "Inheriting capabilities" at LWN. For the full gory details (including some algebraic notation on the capability sets), refer to the capabilities(7) man page.
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
1
Why?CapabilityBoundingSet=: "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."
– sourcejedi
Dec 14 at 23:23
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is thatSecureBits=lackskeep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)
– Filipe Brandenburger
Dec 14 at 23:41
add a comment |
It's correct to say that in general systemd will not work with file capabilities managed with setcap and will require you to configure them as part of the service unit instead.
So it's not like setcap is completely deprecated... (There might be valid uses for it outside of services launched by systemd.) But it doesn't really work for systemd services, at least.
In fact, file capabilities (set by setcap) were always dubious and questionable, from the start... They require the use of "inheritable" capabilities, which were somewhat poorly conceived and had many shortcomings... The kernel feature of "ambient" capabilities was introduced to solve many of these issues and it's what newer systems are adopting (systemd included here, as you can see, you're setting AmbientCapabilities= for your service to manage to be able to bind to low ports.)
The topic of capabilities is fairly complex... For a perhaps gentler introduction to this issue, you might want to check "Inheriting capabilities" at LWN. For the full gory details (including some algebraic notation on the capability sets), refer to the capabilities(7) man page.
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
It's correct to say that in general systemd will not work with file capabilities managed with setcap and will require you to configure them as part of the service unit instead.
So it's not like setcap is completely deprecated... (There might be valid uses for it outside of services launched by systemd.) But it doesn't really work for systemd services, at least.
In fact, file capabilities (set by setcap) were always dubious and questionable, from the start... They require the use of "inheritable" capabilities, which were somewhat poorly conceived and had many shortcomings... The kernel feature of "ambient" capabilities was introduced to solve many of these issues and it's what newer systems are adopting (systemd included here, as you can see, you're setting AmbientCapabilities= for your service to manage to be able to bind to low ports.)
The topic of capabilities is fairly complex... For a perhaps gentler introduction to this issue, you might want to check "Inheriting capabilities" at LWN. For the full gory details (including some algebraic notation on the capability sets), refer to the capabilities(7) man page.
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
answered Dec 14 at 23:08
Filipe Brandenburger
6,8852734
6,8852734
1
Why?CapabilityBoundingSet=: "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."
– sourcejedi
Dec 14 at 23:23
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is thatSecureBits=lackskeep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)
– Filipe Brandenburger
Dec 14 at 23:41
add a comment |
1
Why?CapabilityBoundingSet=: "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."
– sourcejedi
Dec 14 at 23:23
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is thatSecureBits=lackskeep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)
– Filipe Brandenburger
Dec 14 at 23:41
1
1
Why?
CapabilityBoundingSet= : "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."– sourcejedi
Dec 14 at 23:23
Why?
CapabilityBoundingSet= : "If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced."– sourcejedi
Dec 14 at 23:23
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is that
SecureBits= lacks keep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)– Filipe Brandenburger
Dec 14 at 23:41
@sourcejedi I haven't checked this in a while... If I remember correctly, the issue is that
SecureBits= lacks keep-caps, which means capability bounding set is preserved for root but then a transition to a non-root user will end up dropping them... (When I have some time I'll try to take a fresh look at this and add some more details to the answer... Though feel free to go ahead and do that if you feel like it too!)– Filipe Brandenburger
Dec 14 at 23:41
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f488075%2fis-setcap-deprecated%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
setcapworks as if you were setting the SETUID bit on the file, that means that a regular use would gain the extra capabilities listed there, that can be necessary but not when starting a daemon– Bigon
Dec 15 at 9:52