# Can't run a crontab as regular user

## Rocker

Hi,

I try to install a cronjob for a regular user.

When I run crontab -l or something like that, I get the following message:

```

rutger@serveerster rutger $ crontab -l

seteuid: Operation not permitted

```

I already changed the permission of /usr/bin/crontab which are now:

```

rutger@serveerster rutger $ ll /usr/bin/crontab

-rwxr-x---    1 root     cron        20060 Feb 10 09:30 /usr/bin/crontab

```

Before the permissions of this file where set to root.root, but then I recieved the message 'Permission denied', so I changed it to root.cron.

Of course I'm listed in the cron group:

```

rutger@serveerster rutger $ id

uid=1000(rutger) gid=100(users) groups=100(users),16(cron),245(slocate)

```

Does anybody have any idea??

----------

## bobby_j

check to see if there is a cron.allow file

users will be denied access if there is a cron.allow and they aren't in it.  (if there is no cron.allow, i think access is open)

----------

## Rocker

Hi,

I do already have a /etc/cron.allow file, which contains one username on each line. So it looks like:

```

rutger@serveerster rutger $ more /etc/cron.allow

root

rutger

tmfweb

chello

```

AFAIK is this the correct syntax for this file, but correct me if I'm wrong

----------

## indros

Try, if you haven't already, adding the user to the cron group in /etc/group.

----------

## Rocker

```

rutger@serveerster rutger $ less /etc/group | grep cron

cron::16:cron,tmfweb,rutger,chello

```

As you can see does the user already exists in /etc/group

Any other idea where to look at??

----------

## bobby_j

ooh, oh.  

chmod u+s crontab

----------

## Rocker

Hey thanks!!! It works! 

What does those +s option do? Is it from Stickybit?? But what the # is a stickybit exactly??

----------

## indros

Sorry.. I guess I haven't fully waken up, cuz if I had, I wouldn't have posted a suggestion for something you had in your first post...

----------

## Rocker

 *indros wrote:*   

> Sorry.. I guess I haven't fully waken up

 

Never mind... won't blame you....  :Razz: 

----------

## bobby_j

it allows setuid..  message me if you run across any good documentation about it, because i haven't found any. :)

----------

## afcowie

The man page for chmod tells the story though is a bit hard to read.

The man page for ls (look in the blurb for the -l option) explains it a bit as well, and does a nice job of explaining what you'll see if you run ls -l.

Other than that, any "good" book on Unix systems administration will cover the topic. The setuid bit was one of the intreguing features of the very first Unix systems; Dennis Ritchie patented the idea in the early 70s. If you'd like to know more, see: http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf

AfC

----------

## Ubnormal

 *bobby_j wrote:*   

> ooh, oh.  
> 
> chmod u+s crontab

 

If changing u+s on /usr/bin/crontab doesn't solve the problem for you try to mount /usr partition withoun nosuid option in /etc/fstab. I've stuck on this for a few hours  :Smile:  Hope this help to anyone.

----------

## beuselinck

page 75 in http://www.tldp.org/LDP/intro-linux/intro-linux.pdf explains SUID and GUID quite well

----------

## 1clue

This is a slightly stale thread, but since it addresses exactly what I'm concerned about I'll post it here.

The chmod u+s command will cause crontab to be executed as root, no matter who does it.

I use crontab as specific users, for very specific reasons.  Is there some reason why crontab comes default looking like this?

-rws--x--- 1 root cron 29776 Aug 20 14:45 /usr/bin/crontab

This seems to be an invitation a system compromise.  First, only the cron process and root can execute it.  Second, this thread illustrates that the first inclination for most roots will be to fiddle the permissions in a way that seems to not mess with the "funny" permissions.  If you do that incorrectly, you get either something that allows any user to change root's crontab, or you get untested scripts running under root authority.

The real question here is, why did somebody change the permissions of crontab?

----------

## ChrisJumper

 *Quote:*   

> The real question here is, why did somebody change the permissions of crontab?

 

Because  

```
$ crontab -e

You (ChrisJumper) are not allowed to use this program (crontab)

See crontab(1) for more information
```

Realy its a problem which burn out my brain! If i in the group of cron. Why can't i edit it as a cron-member the Crontab?

And why is this not in the Cron-Howto? Or in the Wikis?

Iam still list in /etc/cron.allow too.

And i will not use the stiky-bit to start my jobs as root!

Where can i find the Cron-Tab-File? Which will be open with the crontab -e command? Maybe i have bild this as root and there is my permission-problem.

Yesterday i add me to the group without a new log on my engine. But today... i dont know.

EDIT: Found it!

I realy dont know why.  I use vixie-cron. And now i can edit my crontab if i make this as root:

```

# echo "chrisjumper" >> /etc/cron.allow
```

But now:

```
 # cat /etc/cron.allow 

chrisjumper 

chrisjumper
```

After deleting the first row i have still access. Maybe its a char-set-bug? Before i edit this line with vim

----------

## pharaoh

I just ran into this same problem after a major Gentoo upgrade on my home server.  Whereas cron worked fine for regular users before, now I have to add them into /etc/cron.allow even with /etc/cron.deny being blank.  The users were also already part of the crontab and cron groups, and afterwards I found that adding them into the two groups did nothing.  The users only need to exist in /etc/cron.allow.  Weird.

----------

## 93nt00r0ck5

 *pharaoh wrote:*   

> The users were also already part of the crontab and cron groups, and afterwards I found that adding them into the two groups did nothing.  The users only need to exist in /etc/cron.allow.  Weird.

 

Really?  I removed my user from the cron group and I got permission denied when I logged in and did a 'crontab -l'.  (Before removing my user from the cron group, crontab -l was working perfectly.)  I don't have a crontab group.  Re-adding my user to the cron group, logging out and logging back in allowed me to run 'crontab -l' again.  Also, I have added my user to the /etc/cron.allow and have a blank /etc/cron.deny.  BTW, if it makes any difference, I am using sys-process/vixie-cron-4.1-r9.  I am going to update to 4.1-r10 right now and see if it still works.

Interesting:

```

 * Messages for package sys-process/vixie-cron-4.1-r10:

 * Previous ebuilds didn't correctly set permissions on

 * the crontabs spool directory. Proper permissions are

 * now being set on /var/spool/cron/crontabs/

 * Look at this directory if you have a specific configuration

 * that needs special ownerships or permissions.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 1 config files in '/etc' need updating.

 * See the CONFIGURATION FILES section of the emerge

 * man page to learn how to update config files.

```

I don't think that has anything to do with the previous problem(s), but interesting enough.  BTW, the file that needed to be updated by env-update was /etc/cron.deny.  My blank /etc/cron.deny was replaced with this:

```

# $Id: vixie-cron-4.1-cron.deny,v 1.1 2005/03/04 23:59:48 ciaranm Exp $

# If for any reason you have users in the 'cron' group who should not

# be allowed to run crontab, add them to this file (one username per

# line)

```

This seems to imply that you don't need to add them to cron.allow, just the cron group to "allow" cron access, but cron.deny will work to deny access (but they have to be in the cron group).  Other users NOT in the cron group will be denied w/o having to add them to this file.

Hope this helps someone.

L8r, Andrew

[edit]

Just an FYI, I logged in as root, deleted the /etc/cron.allow, logged in as my normal user, did a crontab -l, it worked.  Re-logged in as root, added my user to /etc/cron.deny (did not re-create /etc/cron.allow), logged in as my normal user again, did a crontab -l, access denied.  So, apparently, you just need to add the user to the cron group to allow cron access.

----------

