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 – 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 (the file owner 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 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).​