Bugzilla – Bug 373654
PERMISSION_SECURITY set to secure by default
Last modified: 2018-12-06 13:17:38 UTC
Is this a new security feature? cfarrell@paddy:~> crontab -e bash: /usr/bin/crontab: Permission denied cfarrell@paddy:~> cfarrell@paddy:~> uname -a Linux paddy 2.6.25-rc5-git3-6-pae #1 SMP 2008-03-14 16:14:49 +0100 i686 i686 i386 GNU/Linux cfarrell@paddy:~> cfarrell@paddy:~> ls -la /usr/bin/crontab -rwsr-x--- 1 root trusted 35216 2008-03-15 16:12 /usr/bin/crontab cfarrell@paddy:~>
$ getfacl /usr/bin/crontab getfacl: Removing leading '/' from absolute path names # file: usr/bin/crontab # owner: root # group: trusted user::rwx group::r-x other::--- This is a regression. In 10.3 /usr/bin/crontab was user-callable: -rwsr-xr-x 1 root trusted 40672 Sep 21 2007 /usr/bin/crontab
This depends on the permissions file you use: # grep "/usr/bin/crontab" /etc/permissions* /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 Maybe our default changed? Reassigning to Ludwig.
maybe factory installs with 'secure' as default. No idea whether that's intended or not.
If we changed to paranoid without intent, then this is a bug as it should not have happened. If we changed to paranoid with intent, then it is a bug not to communicate such a change. What is our default permission setting for 11.0?
Is there any documentation what the purpose of group 'trusted' is? The 4750 setting only makes sense, if the group is used.
from /etc/permissions.secure: # system administrator for advice. In many cases, adding a user to the # "trusted" group gives her access to the resources that are not accessible # any more if the admin chose to select "secure" as the permissions default. I don't think changing the default to secure was intended. The default is not set by the permissions package though but some policy file for yast I think. Reassignig to coolo as he has to decide what permissions level he wants for openSUSE.
what exactly did you install? do you have log files? we surely did not change the default.
(In reply to comment #7 from Stephan Kulow) > what exactly did you install? do you have log files? > > we surely did not change the default. > I did the same as what I always do: ./suse/lnussel/bin/setupgrubfornfsinstall -> SLP scan -> FTP openSUSE 11.0 Build 55 DVD I used the default new installation and changed nothing.
you forgot the log files - /var/log/YaST?
Wild guess, if the default didn't change could it be that SuSEconfig was not run? If this command: $ grep SECU /etc/sysconfig/security says "easy local" it probably wasn't.
Sorry. Log files futsch because I re-installed 10.3.
ok, then this is a dead end. See you next time :)
wait. Dead End for Ciaran only. I claim, it can be reproduces with each and every 11.0 installation. I also tested build55. y2logs appended.
Created attachment 206063 [details] y2logs from my laptop 11.0 install
could you please then answer #10?
The answer is yes. in 11.0 /etc/sysconfig/security contains PERMISSION_SECURITY="secure local" in 10.3 it contained PERMISSION_SECURITY="easy local"
yast2-security: jsuchome
Why is this on YaST? YaST is not responsible for /etc/sysconfig/security
... but it may be a bug in yast2-users, during second-stage write of root/first user.
I found some problem in yast2-users (yast2-users-2.16.23), but I wasn't able to reproduce reported behavior. I hope it will fix the problem, please test again with next Alpha/Beta release.
*** Bug 376819 has been marked as a duplicate of this bug. ***
*** Bug 379373 has been marked as a duplicate of this bug. ***
*** Bug 375155 has been marked as a duplicate of this bug. ***
*** Bug 420995 has been marked as a duplicate of this bug. ***