user access crontab

I’m having a bit of a problem with crontab:

Andy@NAS-Roden:/usr/bin> cat /etc/cron.allow
Andy
Andy@NAS-Roden:/usr/bin> crontab -e
-bash: /usr/bin/crontab: Access denied
Andy@NAS-Roden:/usr/bin> l crontab
-rwsr-x--- 1 root trusted 35876 jun  6  2008 crontab*
Andy@NAS-Roden:/usr/bin> groups
users console dialout trusted tty video xok
Andy@NAS-Roden:/usr/bin> uname -a
Linux NAS-Roden 2.6.26.2-pae #2 Fri Aug 8 21:46:59 CEST 2008 i686 athlon i386 GNU/Linux

What do I need to do to get Andy crontab access?

Thnx,
Andy

In my system:

boven:/usr/bin # l crontab
-rwsr-xr-x 1 root trusted 35288 Sep 22  2007 crontab*
boven:/usr/bin #

When I do

boven:/usr/bin # chmod o-rx crontab
boven:/usr/bin # 

my normal user gets the same error as you get.

I can not tell why tthe permission bits are not set as they should be on your system.

The connection of the normal user to the group trusted is not needed for this.

Try not having a cron.allow. You don’t need it to be able to run crontab as a normal user because the program is suid, so you will be running as root.

hmm.
I removed Andy from the trusted group, deleted cron.allow and I played a bit with chmod.

-rwsr-sr-x 1 root trusted 35876 Jun  6  2008 crontab*

Now crontab -e is allowed.

A bit odd. It seems that less rights is better.:
Many how-to’s are not up to date on this subject.

Thanks for the help.
Andy

The sgid bit should not be set. It is not in my system, so why should you set it. The permission bits I gave you are those set during system installation. No need to change anything there. Is there realy a HOWTO that prescribes this?

I do not know who added Andy to the trusted group and why, but it is not needed for cron usage.

My system has a crontab.deny (with guest in it) and no crontab.allow. The only thing needed for allowing cron usage is in using one of these files (not both). So when most people are allowed and some not, use crontab.deny. When most are to be denied use crontab.allow for the exeptions.

That is all about a HOWTO IMHO. Read man cron and man crontab. Much better then a HOWTO.

The sgid bit was set (just the owner one) but I removed it accidentally. I got it restored, but the one on grouplevel was set aswell. I dunno how to remove that so I leave it. Its not that important to me. Im not even sure that did the trick.

I also added Andy to the trusted group manually. I did this in an attempt to get crontab working for Andy. No luck as you read above. Same thing with cron.allow. It made no difference at all.

I’m not the kind of person who likes to mess around. If it works, I leave it alone.
Crontab simply didnt work for any user other then root, so I had to try something to get it working, cause I don’t want cronjobs running through root.

Andy

To remove the sgid bit

chmod g-s /usr/bin/crontab

see the manpage of chmod!

It made no difference at all.

It may not create the situation you tried to achieve, but of course it makes a difference. These things make holes in your security. These thing alter the behaviour of your system. Maybe after half a year or so you will have strange things happening and of course the correllation with what you did a long time ago will not be seen then.

When you are carefully you may change such things for a test, but when they do not work you should immideatly revert them.

And when you keep them, document them!! For different reasons.

  1. you may want to do this again when you install a new version of the software (update/upgrade or whatever).
  2. when strange things happen later, you may want to recall what you changed to the system.

I agree completely. Setting x on o level is not safe.
But when I assign x on group, add the user to that group, I expect the user to be able to execute the file. This is not the case, and I still don’t know why.
This makes me angry: or I’m stupid cause I don’t understand user rights in Linux, or my system is screwed up and not behaving like it should.

Fortunately its not a business enviroment, nor a machine exposed on the internet. Still I want this to work the way it should.

Regards,
Andy

b.t.w. The only reason crontab worked for Andy was because of x bit on o level. Removing that sets me back to square one.

The setuid and setguid bits are there that when you execute that program the actual uid and guid of the process are set to the owner uid and guid of the file instead of the uid and guid of the caller.

You will see this implemented often which files that are owned by root and have a setuid bit. This is a way to let others execute that program and the process runs ‘under root’. (No need to say that the program must be a thouroughly tested one and have no security holes and being proven that it is what it should be).

So when someone (say henk to name just a random one) calls the program, first henk must have execute allowance. In most cases that means that the r-x bits are set for ‘the world’ (and also for the group as a consequence). Only when the execution is allowed the program starts and the setuid bit then starts doing things, namely changin the user of the process from henk to root.

So there are two things:

  1. you may execute it or not
  2. when you may, uid (and eventual guid) are changed.

This brings us to the fact that when you add a uid to a group, that only influences if he may execute a program that is owned by that group and has the bits set for group (nut not for world, this would be nonsense because evry user can then execute, no need for adding to the group)
In this case:

-rwsr-xr-x 1 root trusted 35288 Sep 22  2007 /usr/bin/crontab*

everybody may execute!!! So no need for adding to group trusted.

And when the process starts it runs with uid root and the group stays what the user had already. No need to change to trusted because (as miriads of systems prove) root is powerfull enough of doing here what should be done. So no need for a setguid bit. (and of course no need for adding to the trusted group because this has nothing to do with this setguid).

I do not know what you talk about setting x on o. Set the bits as they are in this post (and in my earlier post). This is as they were after installation, as they are on almost every system not only now, but already for many years (that is when nobody meddles around with them) and as they should be.

Only use crontab.allow OR crontab.deny.

If anyone comes across this same problem with openSUSE 12.1 or maybe an earlier/later version, this is the reason/solution:

There is a system that checks the permissions of important files/programs. With YaST you can change your file security setting to easy/secure/paranoid
using the ‘Security Center and Hardening’ tool. A program called ‘chkstat’ will then check and change the permissions of the files according to /etc/permissions.*
at boot time. When you set the permissions to secure, this program will (according to permissions.secure) change the permissions of /usr/bin/crontab to
4750 with the owner to root:trusted in order to prevent untrusted people from accessing important files (like crontab).

If you want the old situation back, you can either:

  • Choose the easy permissions option in YaST,
  • Add yourself to the group ‘trusted’, This way you won’t get the warning unsafe profile, the permissions will be
    correct at boot time and it won’t be overwritten when updating some package.
  • A third option is to add the line ‘/usr/bin/crontab root:root 4755’ to /etc/permissions.local. It has the same
    result as adding yourself to ‘trusted’ but the permissions are not safe. Use with caution.

On 12/02/2011 03:46 AM, dsonck92 wrote:
> but the permissions are not safe.

then why not just explain the safe way, and don’t even mention the
unsafe way??


DD
openSUSE®, the “German Engineered Automobiles” of operating systems!

DenverD wrote:
> On 12/02/2011 03:46 AM, dsonck92 wrote:
>> but the permissions are not safe.
>
> then why not just explain the safe way, and don’t even mention the
> unsafe way??

Where’s the fun in that? :slight_smile:

Because “security through obscurity” rarely works – at least not for long. System administrators (even if we’re only talking about a home PC with one or two users) should be aware of both best practice as well as the not-so-great methods that may, nonetheless, be needed in certain “edge” cases. Otherwise, we risk allowing the perfect to become the enemy of the good.

LOVE the signature!

On 2011-12-02 15:18, DenverD wrote:
> On 12/02/2011 03:46 AM, dsonck92 wrote:
>> but the permissions are not safe.
>
> then why not just explain the safe way, and don’t even mention the unsafe
> way??

They are not “unsafe”. Just not so safe.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)