chown removes setuid bit: bug or feature?
Steps to reproduce:
germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov 2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov 2 20:11 test
Tested with Debian squeeze and Ubuntu 12.04
permissions users chown
edited Dec 8 at 21:20
Barmar
6,8981123
asked Nov 2 '12 at 19:18
Germar
232311
add a comment |
Steps to reproduce:
germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov 2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov 2 20:11 test
Tested with Debian squeeze and Ubuntu 12.04
permissions users chown
edited Dec 8 at 21:20
Barmar
6,8981123
asked Nov 2 '12 at 19:18
Germar
232311
Does that on Fedora 17 too.
– BenjiWiebe
Nov 2 '12 at 19:45
1
feature
– mikeserv
Aug 5 '14 at 2:05
add a comment |
Steps to reproduce:
germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov 2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov 2 20:11 test
Tested with Debian squeeze and Ubuntu 12.04
permissions users chown
edited Dec 8 at 21:20
Barmar
6,8981123
asked Nov 2 '12 at 19:18
Germar
232311
Steps to reproduce:
germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov 2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov 2 20:11 test
Tested with Debian squeeze and Ubuntu 12.04
permissions users chown
permissions users chown
edited Dec 8 at 21:20
Barmar
6,8981123
asked Nov 2 '12 at 19:18
Germar
232311
edited Dec 8 at 21:20
Barmar
6,8981123
asked Nov 2 '12 at 19:18
Germar
232311
edited Dec 8 at 21:20
Barmar
6,8981123
edited Dec 8 at 21:20
Barmar
6,8981123
edited Dec 8 at 21:20
Barmar
6,8981123
6,8981123
asked Nov 2 '12 at 19:18
Germar
232311
asked Nov 2 '12 at 19:18
Germar
232311
asked Nov 2 '12 at 19:18
Germar
232311
232311
Does that on Fedora 17 too.
– BenjiWiebe
Nov 2 '12 at 19:45
1
feature
– mikeserv
Aug 5 '14 at 2:05
add a comment |
Does that on Fedora 17 too.
– BenjiWiebe
Nov 2 '12 at 19:45
1
feature
– mikeserv
Aug 5 '14 at 2:05
Does that on Fedora 17 too.
– BenjiWiebe
Nov 2 '12 at 19:45
Does that on Fedora 17 too.
– BenjiWiebe
Nov 2 '12 at 19:45
1
1
feature
– mikeserv
Aug 5 '14 at 2:05
feature
– mikeserv
Aug 5 '14 at 2:05
add a comment |
2 Answers
2
active
oldest
votes
Not a bug according to chown documentation:
$ info coreutils 'chown invocation'
The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits. This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking). When in doubt, check the underlying system behavior.
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
Thanks jlliagre. I didn't knowinfo coreutilsbefore. I only read man-page and searched the web.
– Germar
Nov 2 '12 at 20:59
add a comment |
This is by design, and it's standard behavior. Quoting the POSIX standard:
Unless chown is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.
(s is setuid (or setgid in the group column), not sticky, by the way.)
This behavior follows that of the underlying system call (except that on some systems, the setxid bits are only cleared for executable files).
The reason for removing the setuid bit is that changing the owner also changes which user will be the process's effective user ID. In particular, on systems where a user can give away a file, cp /bin/sh foo; chmod u+s foo; chown joe foo would create a setuid executable belonging to joe, a giant security hole.
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
1
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
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%2f53665%2fchown-removes-setuid-bit-bug-or-feature%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
Not a bug according to chown documentation:
$ info coreutils 'chown invocation'
The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits. This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking). When in doubt, check the underlying system behavior.
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
Thanks jlliagre. I didn't knowinfo coreutilsbefore. I only read man-page and searched the web.
– Germar
Nov 2 '12 at 20:59
add a comment |
Not a bug according to chown documentation:
$ info coreutils 'chown invocation'
The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits. This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking). When in doubt, check the underlying system behavior.
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
Thanks jlliagre. I didn't knowinfo coreutilsbefore. I only read man-page and searched the web.
– Germar
Nov 2 '12 at 20:59
add a comment |
Not a bug according to chown documentation:
$ info coreutils 'chown invocation'
The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits. This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking). When in doubt, check the underlying system behavior.
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
Not a bug according to chown documentation:
$ info coreutils 'chown invocation'
The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits. This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking). When in doubt, check the underlying system behavior.
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
answered Nov 2 '12 at 20:39
jlliagre
46.3k783132
46.3k783132
Thanks jlliagre. I didn't knowinfo coreutilsbefore. I only read man-page and searched the web.
– Germar
Nov 2 '12 at 20:59
add a comment |
Thanks jlliagre. I didn't knowinfo coreutilsbefore. I only read man-page and searched the web.
– Germar
Nov 2 '12 at 20:59
Thanks jlliagre. I didn't know
info coreutils before. I only read man-page and searched the web.– Germar
Nov 2 '12 at 20:59
Thanks jlliagre. I didn't know
info coreutils before. I only read man-page and searched the web.– Germar
Nov 2 '12 at 20:59
add a comment |
This is by design, and it's standard behavior. Quoting the POSIX standard:
Unless chown is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.
(s is setuid (or setgid in the group column), not sticky, by the way.)
This behavior follows that of the underlying system call (except that on some systems, the setxid bits are only cleared for executable files).
The reason for removing the setuid bit is that changing the owner also changes which user will be the process's effective user ID. In particular, on systems where a user can give away a file, cp /bin/sh foo; chmod u+s foo; chown joe foo would create a setuid executable belonging to joe, a giant security hole.
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
1
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
add a comment |
This is by design, and it's standard behavior. Quoting the POSIX standard:
Unless chown is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.
(s is setuid (or setgid in the group column), not sticky, by the way.)
This behavior follows that of the underlying system call (except that on some systems, the setxid bits are only cleared for executable files).
The reason for removing the setuid bit is that changing the owner also changes which user will be the process's effective user ID. In particular, on systems where a user can give away a file, cp /bin/sh foo; chmod u+s foo; chown joe foo would create a setuid executable belonging to joe, a giant security hole.
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
1
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
add a comment |
This is by design, and it's standard behavior. Quoting the POSIX standard:
Unless chown is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.
(s is setuid (or setgid in the group column), not sticky, by the way.)
This behavior follows that of the underlying system call (except that on some systems, the setxid bits are only cleared for executable files).
The reason for removing the setuid bit is that changing the owner also changes which user will be the process's effective user ID. In particular, on systems where a user can give away a file, cp /bin/sh foo; chmod u+s foo; chown joe foo would create a setuid executable belonging to joe, a giant security hole.
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
This is by design, and it's standard behavior. Quoting the POSIX standard:
Unless chown is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.
(s is setuid (or setgid in the group column), not sticky, by the way.)
This behavior follows that of the underlying system call (except that on some systems, the setxid bits are only cleared for executable files).
The reason for removing the setuid bit is that changing the owner also changes which user will be the process's effective user ID. In particular, on systems where a user can give away a file, cp /bin/sh foo; chmod u+s foo; chown joe foo would create a setuid executable belonging to joe, a giant security hole.
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
answered Nov 4 '12 at 0:23
Gilles
526k12710561580
526k12710561580
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
1
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
add a comment |
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
1
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Upvoting for the nitpick! SUID/SGID are not the "sticky" bit!
– Jim Dennis
Jul 13 '17 at 19:29
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
Great point about the security implications of preserving SUID/SGID. I was bothered by the behavior until I read that sentence. I would add, however, I've never seen chown not clear the bits, even when running as root. I'm curious what "appropriate privileges" would imply.
– vastlysuperiorman
Aug 17 '17 at 4:52
1
1
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
@vastlysuperiorman On a classical Unix platform, “appropriate privileges” means user ID 0. But POSIX allows systems to define their own security policies. For example, for many operations on Linux, “appropriate privileges” is implemented as a capability (which only root gets by default). In this particular case, does suppress setxid bits on chown regardless of privileges, like most if not all Unix variants. But a POSIX layer on Windows might work differently.
– Gilles
Aug 17 '17 at 8:45
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%2f53665%2fchown-removes-setuid-bit-bug-or-feature%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
Does that on Fedora 17 too.
– BenjiWiebe
Nov 2 '12 at 19:45
1
feature
– mikeserv
Aug 5 '14 at 2:05