I'm having a problem with chmod command.
I have a directory with sgid, suid and sticky bit on.
If I then run chmod u=rwx {dirname} or chmod g=rwx {dirname} sgid and suid are still on.
But if I run chmod o=rwx sticky bit removes.
Can anyone explain why it happens?
Asked
Active
Viewed 357 times
1
Romeo Ninov
- 16,541
- 5
- 32
- 44
user388601
- 13
- 2
-
Did you try `o+rwx`? – Romeo Ninov Jan 02 '20 at 10:37
-
Yes, it leaves sticky bit on. But the problem is with =. I mean u=r wouldn't remove uid, but o=r would remove sticky bit. – user388601 Jan 02 '20 at 10:48
-
AFAIK suid and guid have no effect on directories. And maybe this is the reason – Romeo Ninov Jan 02 '20 at 10:50
-
On a certified UNIX, it works the way you like. Did you try to make a bug report against yout local `chmod` program? – schily Jan 02 '20 at 11:18
-
@RomeoNinov suid has no effect on directories, however sgid does. (At least this is true of Gnu/Linux). – ctrl-alt-delor Jan 02 '20 at 12:13
1 Answers
2
From man chmod on Debian 10:
For directories chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like
u+sandg-s. To clear these bits for directories with a numeric mode requires an additional leading zero, or leading = like00755, or=755
No such explicit guarantee is made for the sticky bit. So the behavior matches the documentation.
Why chmod is designed to behave that way is a more difficult question.
It might be because set-user-ID or set-group-ID bits may grant additional privileges while the sticky bit on directories causes a further restriction: if the suid/sgid bits are accidentally removed from a directory, the user might or might not be able to put them back on (e.g. an user-owned directory with a group the user is not a member of), and might need to ask the system administrator to help; but in the case of the sticky bit, the user can simply toggle it back on as needed.
telcoM
- 87,318
- 3
- 112
- 232
-
Although POSIX does indicate (in the specifications for `sys/stat.h` and `chmod`) that the restricted deletion flag is not part of the `o` (or `u` or `g`) permission bits and so should not be affected by an `o=` symbolic mode. – JdeBP Jan 02 '20 at 11:46
-
That's true, so the only way to get a sure answer would be to ask the developers of the specific implementation the OP is seeing the behavior on. And since they did not specify the OS, let alone its version, only the OP can do that. – telcoM Jan 02 '20 at 11:56
-
Well the question _did_ have the XUbuntu tag, Which would imply GNU Coreutils' `chmod`. And historically ([according to NEWS](https://github.com/coreutils/coreutils/blob/aaba82431ceca97441d56152d8c7ec2d84fa1d12/NEWS#L3561)) the Coreutils people have preferred the choice of _not_ changing the 06000 flags unless explicit, a choice whose rationale logically extends to the restricted deletion flag. – JdeBP Jan 02 '20 at 12:08
-
Just because the local chmod documents this behavior,it is not correct. – schily Jan 02 '20 at 13:30
-