Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: user access crontab

  1. #1

    Default user access crontab

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

    Code:
    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

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,851

    Default Re: user access crontab

    In my system:
    Code:
    boven:/usr/bin # l crontab
    -rwsr-xr-x 1 root trusted 35288 Sep 22  2007 crontab*
    boven:/usr/bin #
    When I do
    Code:
    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.
    Henk van Velden

  3. #3
    Join Date
    Jun 2008
    Location
    UTC+10
    Posts
    9,686
    Blog Entries
    4

    Default Re: user access crontab

    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.

  4. #4

    Default Re: user access crontab

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

    Code:
    -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

  5. #5
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,851

    Default Re: user access crontab

    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.
    Henk van Velden

  6. #6

    Default Re: user access crontab

    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

  7. #7
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,851

    Default Re: user access crontab

    To remove the sgid bit
    Code:
    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.
    Henk van Velden

  8. #8

    Default Re: user access crontab

    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.

  9. #9
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,851

    Default Re: user access crontab

    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:
    Code:
    -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.
    Henk van Velden

  10. #10

    Lightbulb Re: user access crontab

    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.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •