In Ubuntu 14.04, listing the contents of the directory /var/spool/cron with ls -l provides the following permissions on the directories within (irrelevant columns snipped):

drwxrwx--T daemon daemon atjobs
drwxrwx--T daemon daemon atspool
drwx-wx--T root crontab crontabs

What purpose does setting a sticky bit on a directory without the executable bit serve?

  • But those directories do have executable bits set.
    – user253751
    Apr 28 '17 at 22:11

From the manual page for sticky:


A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

Any user may create a sticky directory. See chmod(1) for details about modifying file modes.

The upshot of this is that only the owner of a file in a sticky directory can remove the file. In the case of the cron tables, this means that I can't go in there and remove your cron table and replace it with one of my choosing, even though I may have write access to the directory. It is for this reason that /tmp is also sticky.

  • 1
    Agreed, but I think what's confusing the OP is why this would be done to a directory that isn't world-writeable. Only the user daemon and members of that group would be able to do anything in atjobs anyway. I assume the devs were thinking of cases where more than that user belonged to the daemon group. Can't really think of any other reason to do this.
    – terdon
    Apr 28 '17 at 16:18
  • In cases where the directory is not world-writable or world-executable, it's simply an additional layer of security in case this is changed by an errant chmod a+wx. This is speculation, but it may be the case that the sticky bit was placed in historical distribution releases, and the owner changed more recently, and there's no reason to not have sticky set in these cases, so "if it ain't broke, don't break it".
    – DopeGhoti
    Apr 28 '17 at 16:22
  • 1
    @terdon hits the nail on the head. I was under the impression that the sticky bit was fairly useless on any directory that wasn't world-writable, and that a capital S or T for the set{u,g}id bits and sticky bit was a warning to get your head out and use them properly.
    – Q23
    Apr 28 '17 at 16:45
  • @Q23, on the other hand, if the owner or group don't have execute permission, it doesn't prevent others getting the benefit from the setuid or setgid bits. Sure, removing your own execute permission from your own file would be weird, but I don't think it stops the set[ug]id bits from working.
    – ilkkachu
    Apr 28 '17 at 16:56
  • 1
    If the directory is group-writable, it means that group members can't remove each others' files.
    – Barmar
    Apr 28 '17 at 20:29

What purpose does setting a sticky bit on a directory without the executable bit serve?

drwx-wx--T 2 root crontab 4096 Apr 24 15:00 /var/spool/cron/crontabs/

What you're looking at is similar on Debian. The directory does have the executable bit set, for the owner and the group. Just for the owner, sticky doesn't make much sense, since that's by definition only one user (and the owner gets to override sticky anyway). But for the group, it matters exactly as much as for world-writable directories like /tmp, namely that regular users can't remove files belonging to other users.

But why would anyone be a member of the group crontab?

To be able to modify their crontabs, of course! Debian's crontab works with setgid privilege, thus allowing any regular user to access that directory, with their own UID, and with the GID of crontab. That's slightly safer than letting them run crontab with setuid privilege since keeps the users separated from each other.

-rwxr-sr-x 1 root crontab 36008 Jun 11  2015 /usr/bin/crontab

Now, normally, the files in the directory are owned and named by their respective owners, and if crontab only allows to remove the user's own crontab, there shouldn't be a problem. Having the file permissions set up like that works to protect from bugs in the program, and makes the actual UID of the accessing user relevant, not just their name.

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.