# crontab no longer allowed as non-root user

## toralf

I'm "suddenly" faced at 2 hardened Gentoo systems with the fact, that non-root is no longer allowed to run "crontab -l". At my desktop I do get 

```
'/var/spool/cron/crontabs' is not a directory, bailing out.
```

 whilst and at my server I get 

```
You (tfoerste) are not allowed to access to (crontab) because of pam configuration.
```

I *know* that I could change the crontab as no-root user yesterday at my server. Since then I just striped down the kernel .config at my server and booted into the new kernel.

At my desktop I could solve the issue by 

```
usermod -a -G cron,crontab tfoerste
```

 but the same won't help at my server.Last edited by toralf on Sat Oct 27, 2018 5:55 pm; edited 1 time in total

----------

## eccerr0r

Which flavor of cron are you using (cronie? vixie? anacron?)

Did you do etc-update of your /etc/pam.d/cron config to make sure it's up to date?

----------

## toralf

 *eccerr0r wrote:*   

> Which flavor of cron are you using (cronie? vixie? anacron?)
> 
> Did you do etc-update of your /etc/pam.d/cron config to make sure it's up to date?

 No outstanding configs, I do use vixie-cron here at a stable hardened Gentoo. My biggest concern is, that it worked definitely yesterday and since then I just tested different (smaller) kernel configs.

UpdateSry, I do have sys-process/cronie/UpdateLast edited by toralf on Sat Oct 27, 2018 8:59 pm; edited 2 times in total

----------

## eccerr0r

As a debug step, is /var/spool/cron/crontabs really "not" a directory -- ugh, that would be a crontab deceptive diagnostic bug.  boo...

Vixie-cron setups would need users to be in the cron group to use /usr/bin/crontab, (crontab is optional, as /usr/bin/crontab is normally SGID (set group id instead of set user id) crontab.  If your hardened config perhaps disables SGID then you will see this issue, perhaps /usr/bin is on a different filesystem that doesn't do SGID?)

----------

## toralf

The directories are the same at both systems, the permissions too. The difference is definitely the kernel .config. But why does a (special configured) linux kernel yields into such a strange error message?

BTW at the desktop it helps just to be in group "cron", the group "crontab" is not needed. I'd expect the opposite.

----------

## eccerr0r

I'd look into the SUID/SGID handling.  Is the permissions of the crontab binary the same as well?  Are there other SUID/SGID binaries that now fail, or perhaps you can (dangerously) temporarily make a copy of bash that's sgid to test if you can write into the /var/spool/cron/crontabs directory.

Are you using extended attributes?

BTW what hardened sources are you using and what configs did you remove/add?

Yes, I think the group names aren't completely clear.  I think that it's set that 'cron' is a user that's authorized to use cron and thus crontab, and group 'crontab' is actually for the crontab binary (which is setgid).  Both need to be effectively set in order for a user to actually use cron -- just a maze of rules to get through for it to work :)

----------

## toralf

Well

```
CONFIG_EXT4_FS_SECURITY=y
```

is needed at my hardened server with 4.18.6 (and EXT4 for /)

Althought I do have the same kernel setting at my hardened client (BTRFS) a non-root user needs to be in group "cron" too (with kernel 4.19.0) there.

----------

## eccerr0r

I guess this is where it's time for me to learn more about SELinux, if that's what you're using?

Seems like setuid and setgid programs aren't honored if users aren't preauthorized to use them, but this shouldn't have changed from before...

----------

## toralf

I use a hardened profile with a vanilla kernel - no special SElinux/GRsecurity flavour or so.

I'm still wondering about the differences in the group set I do need. Well, maybe I should upgrade the kernel at the server too to check, whether the new kernel version has an effect.

----------

