no permission to run `crontab -e` as normal user

Hi all,

I’ve reinstalled my system due to hard drive replace. The install media is the DVD image of openSUSE Tumbleweed snapshot 20170429. Now, it’s upgraded to snapshot 20170502. I have a problem to use cron in this system.

As a normal user, when I run,

$ crontab -e

It says I have no permission,

bash: /usr/bin/crontab: Permission denied

But this works fine before this reinstall. And as I remembered, I had never messed with the permission of system files. The permission to cron command looks not right,

$ ls -al /usr/bin/crontab
-rwsr-x--- 1 root root 55944 Apr  7 13:02 /usr/bin/crontab

$ stat /usr/bin/crontab
  File: /usr/bin/crontab
  Size: 55944           Blocks: 112        IO Block: 4096   regular file
Device: 29h/41d Inode: 106301      Links: 1
Access: (4750/-rwsr-x---)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-05-05 09:12:02.334125600 +0100
Modify: 2017-04-07 13:02:40.000000000 +0100
Change: 2017-05-02 23:19:09.047968872 +0100
 Birth: -

So, does anyone know whether crontab is disabled for normal user in Tumbleweed, at least new snapshots? Should I issue the following command to make crontab accessible to normal user?

$ sudo chmod o+rx /usr/bin/crontab

Or something else? I am not bold enough to mess with system files because I am not sure I can restore them to default easily.

Thanks in advance for your help.

On my 3.1 system:

henk@boven:~> ls -l $(which crontab)
-rwsr-xr-x 1 root trusted 55792 19 jan  2015 /usr/bin/crontab

And on my 42.2 system it is the same.

There is defiintely something wrong with the (group) ownership and the permissions of your crontab.

You could of course cure that with chown and chmod statments, but the big guestion is: How could this happen?

Thanks Henk. That’s what concerns me.

I have no idea on the reason. Maybe I should do another installation to see whether it’s the same.

In addition, it seems that only /usr/bin/crontab has a different permission set to other files in the same folder,

cnzhx@a:~> ls -al /usr/bin/c[rs]*
-r-xr-xr-x 1 root root   1043 Aug 17  2016 /usr/bin/crc32
-rwxr-xr-x 1 root root   4595 Sep 17  2016 /usr/bin/create-jar-links
-rwxr-xr-x 1 root root 114352 Apr 18 13:01 /usr/bin/crlutil
-rwsr-x--- 1 root root  55944 Apr  7 13:02 /usr/bin/crontab
lrwxrwxrwx 1 root root      9 Jan 31 11:49 /usr/bin/csh -> /bin/tcsh
-rwxr-xr-x 1 root root  52200 Mar 22 02:46 /usr/bin/csplit

My 31.1

These are the ones that have group trusted:

henk@boven:/usr/bin> ls -l | grep trusted
-rwsr-xr-x 1 root trusted    56392 14 okt  2015 at
-rwsr-xr-x 1 root trusted    55792 19 jan  2015 crontab
-rwsr-xr-x 1 root trusted    31504 29 mei  2015 fusermount

Of course at and crontab are related.

It looks as if that group can be used in e.g. a sudoers configuration or the like. AFAIK, openSUSE does not use it.

In any case the x-bit for others should be there.
I wonder if this is something new that now shows in Tumbleweed because that is as rolling release showing first new (or newly broken) things.

I am really curious about other comments.

Sorry I’m not looking carefully enough. Inspired by your comments, I checked my system again. There is no file belonging to group ‘trusted’ in this folder. And the 3 files you mentioned including crontab have the same situation in my system,

cnzhx@a:/usr/bin> ls -l | grep trusted
cnzhx@a:/usr/bin> ls -l | grep "\-rwsr\-x\-\-\-"
-rwsr-x--- 1 root root      52336 Oct 16  2016 at
-rwsr-x--- 1 root root      55944 Apr  7 13:02 crontab
-rwsr-x--- 1 root root      31552 Oct 16  2016 fusermount

Maybe this is something new in Tumbleweed. I need to install it in a VM to find out if this is the case. But I don’t have time to do it until 10 days later.

P.S. Do you happen to know some tricks to check this from the repository or somewhere in the openQA system or else?

P.P.S. I don’t even have ‘trusted’ group in my system,

$ cut -d: -f1 /etc/group | grep trusted

shows nothing.

It looks indeed if something has fundamentally changed here.

When you are sure this is directly from the repos, then it is worth a bug report.

Will do that when I can confirm it.

Thank you, Henk, for all your help :slight_smile:

Y ou are welcome.

Please post a link to the bug report here in the thread when you made one. That will enable others to add to the discussion there.

I tested this with a virtual machine and confirmed the situation. This has been reported just now. The bug report is here:

Thanks. I will watch it with curiousness.

Please vote for the real bug …

mentioned fix was:
chkstat --system
groupadd --system --gid 42 trusted
chkstat --system