Bug 1088235 - Wrong permissions on /usr/bin/crontab
Wrong permissions on /usr/bin/crontab
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Security Team bot
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-05 02:05 UTC by Larry Finger
Modified: 2018-04-06 08:46 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Finger 2018-04-05 02:05:22 UTC
When trying to use "crontab -e" to modify my chron jobs that had previously been set for TW, I suddenly got a permissions error on /etc/bin/crontab. Upon investigation, I found the permissions to be 4750, even though file 
/etc/sysconfig/security, has PERMISSION_SECURITY="easy local".

finger@Larrylap:~/linux-2.6> sudo chkstat -system
Checking permissions and ownerships 
- using the permissions files /etc/permissions /etc/permissions.easy /etc/permissions.d/postfix /etc/permissions.d/texlive /etc/permissions.local setting /var/cache/man/ to man:root 0755. (wrong owner/group man:man) 
setting /var/log/lastlog to root:root 0644. (wrong owner/group root:utmp permissions 0664) 
setting /var/log/btmp to root:utmp 0600. (wrong permissions 0660) /usr/bin/at: unknown group trusted /usr/bin/crontab: 
unknown group trusted /usr/bin/fusermount: 
unknown group trusted /sbin/pccardctl: unknown group trusted

As expected, /etc/group is lacking group trusted.

FWIW, both Leap15 and Leap42.3 have the expected permissions (4755) on /etc/crontab.
Comment 1 Matthias Gerstner 2018-04-05 08:33:06 UTC
Hello and thank you for your report.

I see two separate issues here:

A) Your /usr/bin/crontab seem to be 4750 although you have permissions set to
   easy.

B) You are missing the trusted group in /etc/groups.

Regarding A) the `chkstat --system` should apply the correct settings. If not
then something is probably wrong in the configuration files. Can you please
provide the output of:


Regarding B) the trusted group should be setup via the package
'system-users-root'. Please check whether it is installed and install it or
reinstall it. However, it looks like the package only adds the trusted group
if no /etc/group is existing yet.

I am adding the system-users-root maintainer to this bug for clarification.
Comment 2 Matthias Gerstner 2018-04-05 10:38:32 UTC
Sorry, theres some lines missing from comment 1. Was supposed to say: Can you
please provide the output of:

  root# fgrep bin/crontab /etc/permissions*
  root# fgrep bin/crontab /etc/permissions.d/*
Comment 3 Thorsten Kukuk 2018-04-05 10:58:14 UTC
(In reply to Matthias Gerstner from comment #1)

> Regarding B) the trusted group should be setup via the package
> 'system-users-root'. Please check whether it is installed and install it or
> reinstall it. However, it looks like the package only adds the trusted group
> if no /etc/group is existing yet.
> 
> I am adding the system-users-root maintainer to this bug for clarification.

Correct, this package only creates the group if it is a fresh installation, on update it should always be available either from aaa_base in the past or system-users-root now.
So either there was an error during fresh installation, or during upgrade at some point in time.
Comment 4 Larry Finger 2018-04-05 16:30:21 UTC
This was a clean install of a TW snapshot. Sorry, I do not remember the release date, and it has been updated with "zypper dup" many times.

finger@Larrylap:~> sudo fgrep bin/crontab /etc/permissions*
grep: /etc/permissions.d: Is a directory
/etc/permissions.easy:/usr/bin/crontab                                        root:trusted      4755
/etc/permissions.paranoid:/usr/bin/crontab                                        root:trusted      0755
/etc/permissions.secure:/usr/bin/crontab                                        root:trusted      4750

sudo fgrep bin/crontab /etc/permissions.d/* produces no output.

I removed system-user-group accepting the conflict with package filesystem, moved /etc/group to /etc/group.save, and reinstalled system-user-group.

finger@Larrylap:~/rtlwifi_new> sudo zypper in system-user-root
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  system-user-root

1 new package to install.
Overall download size: 8.0 KiB. Already cached: 0 B. After the operation, additional 186.0 B will be used.
Continue? [y/n/...? shows all options] (y): 
Retrieving package system-user-root-20170617-1.8.noarch                                                                            (1/1),   8.0 KiB (  186   B unpacked)
Retrieving: system-user-root-20170617-1.8.noarch.rpm 
Checking for file conflicts: 
(1/1) Installing: system-user-root-20170617-1.8.noarch 

The resulting /etc/group had only 4 entries:
root:x:0:
shadow:x:15:
trusted:x:42:
users:x:100:

That did not seem correct, thus I copied the entry for trusted into the saved version, and renamed it back to /etc/group. I then ran chkstat:

finger@Larrylap:~> sudo cp /etc/group.save /etc/group
finger@Larrylap:~> sudo chkstat --system
Checking permissions and ownerships - using the permissions files
        /etc/permissions
        /etc/permissions.easy
        /etc/permissions.d/postfix
        /etc/permissions.d/texlive
        /etc/permissions.local
setting /var/cache/man/ to man:root 0755. (wrong owner/group man:man)
setting /usr/bin/at to root:trusted 4755. (wrong owner/group root:root permissions 4750)
setting /usr/bin/crontab to root:trusted 4755. (wrong owner/group root:root permissions 4750)
setting /usr/bin/fusermount to root:trusted 4755. (wrong owner/group root:root permissions 4750)
setting /sbin/pccardctl to root:trusted 4755. (wrong owner/group root:root permissions 4750)

Now crontab has the correct permissions and group.

I looks as if this is a one-of-a-kind failure. I have a couple of TW virtual machines that I use for testing the VirtualBox guest modules. Both of them have the correct permissions for crontab.

I think we can change this bug to RESOLVED/INVALID.
Comment 5 Matthias Gerstner 2018-04-06 08:46:19 UTC
Yes the system-user-root package only adds the very basic groups. You can
manually merge the missing groups to your original group file.

Since you're on Tumbleweed rolling release there are many states that you can
end up that nobody has thought about before. Maybe this happened to you.

I think with the explanation so far you can get things working as desired
again.

Closing as RESOLVED/INVALID. Thank you.