Why is /var/cron/tabs unreadable by the regular users?

[tembun]

I have a simple shell scripts that makes a small system backup using tar(1): it backs up only my personal directory under /home, and configuration files in /etc, /boot/loader.conf and others, so I can run it as my regular user. I'd also like to backup my crontab files, but as a regular user, I can't read this directory:

$ ls -ld /var/cron/tabs
drwx------  2 root wheel 512 Jun  2 22:14 /var/cron/tabs

crontab(1) says:

Each user can have their own crontab, and though these are files in /var/cron/tabs, 
hey are not intended to be edited directly.

That makes sense to me, and I understand that it's much safer to edit them with a special tool, because it checks the syntax for instance. But I can't understand why /var/cron/tabs has such strict permission even for the wheel group. /var/cron by the way has different permissions:

ls -ld /var/cron
drwxr-x---  3 root wheel 512 Nov 28  2025 /var/cron

I know that I can (and I'm supposed to) read crontabs with crontab -l, but this way I can't backup them with tar(1) without writing an extra logic for these specific files.

I also know that I can just change the permissions for this directory (just to see files inside it), but I don't really like to change system defaults, because they are almost always quite sensible. But I can't understand this one.

Do you know why it has such permissions? And is it a way to read these files (and backup them) without changing permissions?

 

[bakul]

A normal user should not be able to read other people's crontabs for privacy reasons. Backup everything as root.

 

[tembun]

A normal user should not be able to read other people's crontabs for privacy reasons. Backup everything as root.

That makes sense. Although if I designed it, I guess I would probably make each directory under /var/cron/tabs readable by the group of the user who owns it.

 

[kent_dorfman766]

That makes sense. Although if I designed it, I guess I would probably make each directory under /var/cron/tabs readable by the group of the user who owns it.

allowing a user to even see if another has a crontab file can be considered a security risk. User A should not even know if user B has a crontab.

Of course you are free to make /var/cron/tabs readable by others as your use case needs dictate.

 

[tembun]

allowing a user to even see if another has a crontab file can be considered a security risk. User A should not even know if user B has a crontab.

I can partially understand this from personal perspective, like, other users shouldn't care about what I have in my crontabs (like what I have in my personal files). But I can't understand why is the very fact that A knows that B has a crontab (without knowing its content) considered to be a security risk? How can I potentially harm user B, if I can't even read his crontabs anyway?

 

[Maturin]

I don't know why exactly /var/cron/tabs/ is by default unreadable for the common user. It may be a privacy thing, it may be a security thing, but it may be also just for preventing users to edit their crontabs manually instead of using crontab -e.
Anyway, as root you can simply change the permissions if you think it's a good thing, causes no problems, and you must have it.
But if

this way I can't backup them

is all what you concerned off:
I don't backup my crontabs. root does. As root does all the backing up of anything system related, like
/etc/, /boot/loader.conf, /usr/local/etc/ etc.
And if you must backup your user's crontab by yourself, just do a crontab -l > BU_mycrontab.txt which copies your crontab to a text file you can simply add to your BU routine.

 

[SirDice]

And if you must backup your user's crontab by yourself, just do a crontab -l > BU_mycrontab.txt which copies your crontab to a text file you can simply add to your BU routine.

You can crontab it

crontab -l > $HOME/backups/crontab-$(date +%Y%m%d)

Schedule this daily.

 

[Maturin]

...of course.
and the

crontab-$(date +%Y%m%d)

is a nice touch.
We just had it with my shellscripting skills in another thread.

 

[Kai Burghardt]

crontab(1) – the program owned by root and set user ID bit set – does not chown(2) the tables back to the getresuid(2) user (‑u is wrong since root might install a crontab for a daemon user or similar) because the file owner can always chmod(2) the file, thus circumventing the whole crontab(1) gatekeeping mechanism (assuming that the necessary path traversal bits [x] were set the file owner simply sets the writable bit and then edits the /var/cron/tabs/$USER directly). Mind that crontab(1) has, beside the syntax checking, also some allow/deny logic.

PS: You could employ ⟨user name⟩ is also a ⟨group name⟩ pattern (i. e. the user kb has as its principal group [stored in passwd(5)] a group named kb), so only group ownership and the group‐readable bit are set; the file ownership remains with root preventing a chmod(1). However, this is not a standard, so as the programmer of crontab(1) you cannot blindly assume anything (and making it configurable unnecessarily complicates things – KISS).​