1

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?

5
  • Did you try o+rwx? Jan 2 '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 2 '20 at 10:48
  • AFAIK suid and guid have no effect on directories. And maybe this is the reason Jan 2 '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 2 '20 at 11:18
  • @RomeoNinov suid has no effect on directories, however sgid does. (At least this is true of Gnu/Linux). Jan 2 '20 at 12:13
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+s and g-s. To clear these bits for directories with a numeric mode requires an additional leading zero, or leading = like 00755 , 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.

5
  • 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 2 '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 2 '20 at 11:56
  • Well the question did have the XUbuntu tag, Which would imply GNU Coreutils' chmod. And historically (according to NEWS) 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 2 '20 at 12:08
  • Just because the local chmod documents this behavior,it is not correct.
    – schily
    Jan 2 '20 at 13:30
  • It is Xubuntu, right
    – user388601
    Jan 2 '20 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.