Bingo!
Both of them should have -rwsr-xr-x.
It should be “chkstat --system” and you have to run it as root, so try that again, it should fix the file permissions.
If not, do this:
chmod u+s /usr/bin/su
chmod u+s /usr/bin/sudo
This is the output of chkstat --system
linux-ug79:~ # chkstat --system
Checking permissions and ownerships - using the permissions files
/etc/permissions
/etc/permissions.easy
/etc/permissions.d/mail-server
/etc/permissions.d/postfix
/etc/permissions.local
setting /usr/lib/utempter/utempter to root:utmp 2755. (wrong permissions 0775)
/usr/lib/utempter/utempter: will not give away s-bits on an insecure path
setting /usr/bin/at to root:trusted 4755. (wrong permissions 0775)
/usr/bin/at: will not give away s-bits on an insecure path
setting /usr/bin/crontab to root:trusted 4755. (wrong permissions 0775)
/usr/bin/crontab: will not give away s-bits on an insecure path
setting /usr/bin/gpasswd to root:shadow 4755. (wrong permissions 0775)
/usr/bin/gpasswd: will not give away s-bits on an insecure path
setting /usr/bin/newgrp to root:root 4755. (wrong permissions 0775)
/usr/bin/newgrp: will not give away s-bits on an insecure path
setting /usr/bin/passwd to root:shadow 4755. (wrong permissions 0775)
/usr/bin/passwd: will not give away s-bits on an insecure path
setting /usr/bin/chfn to root:shadow 4755. (wrong permissions 0775)
/usr/bin/chfn: will not give away s-bits on an insecure path
setting /usr/bin/chage to root:shadow 4755. (wrong permissions 0775)
/usr/bin/chage: will not give away s-bits on an insecure path
setting /usr/bin/chsh to root:shadow 4755. (wrong permissions 0775)
/usr/bin/chsh: will not give away s-bits on an insecure path
setting /usr/bin/expiry to root:shadow 4755. (wrong permissions 0775)
/usr/bin/expiry: will not give away s-bits on an insecure path
setting /usr/bin/sudo to root:root 4755. (wrong permissions 0775)
/usr/bin/sudo: will not give away s-bits on an insecure path
setting /usr/bin/eject to root:audio 4755. (wrong permissions 0775)
/usr/bin/eject: will not give away s-bits on an insecure path
setting /usr/bin/fusermount to root:trusted 4755. (wrong permissions 0775)
/usr/bin/fusermount: will not give away s-bits on an insecure path
setting /usr/lib/gnome-pty-helper to root:utmp 2755. (wrong permissions 0775)
/usr/lib/gnome-pty-helper: will not give away s-bits on an insecure path
setting /usr/bin/v4l-conf to root:video 4755. (wrong permissions 0775)
/usr/bin/v4l-conf: will not give away s-bits on an insecure path
setting /usr/bin/wall to root:tty 2755. (wrong permissions 0775)
/usr/bin/wall: will not give away s-bits on an insecure path
setting /usr/bin/write to root:tty 2755. (wrong permissions 0775)
/usr/bin/write: will not give away s-bits on an insecure path
setting /usr/lib/libgnomesu/gnomesu-pam-backend to root:root 4755. (wrong permissions 0775)
/usr/lib/libgnomesu/gnomesu-pam-backend: will not give away s-bits on an insecure path
setting /usr/bin/fileshareset to root:root 4755. (wrong permissions 0775)
/usr/bin/fileshareset: will not give away s-bits on an insecure path
setting /usr/lib/polkit-1/polkit-agent-helper-1 to root:root 4755. (wrong permissions 0775)
/usr/lib/polkit-1/polkit-agent-helper-1: will not give away s-bits on an insecure path
setting /usr/bin/pkexec to root:root 4755. (wrong permissions 0775)
/usr/bin/pkexec: will not give away s-bits on an insecure path
setting /usr/sbin/lockdev to root:lock 2755. (wrong permissions 0775)
/usr/sbin/lockdev: will not give away s-bits on an insecure path
setting /usr/bin/su to root:root 4755. (wrong permissions 0775)
/usr/bin/su: will not give away s-bits on an insecure path
setting /usr/bin/mount to root:root 4755. (wrong permissions 0775)
/usr/bin/mount: will not give away s-bits on an insecure path
setting /usr/bin/umount to root:root 4755. (wrong permissions 0775)
/usr/bin/umount: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
linux-ug79:~ #
The same as last time
I have done the other suggestion
linux-ug79:~ # chmod u+s /usr/bin/su
linux-ug79:~ # chmod u+s /usr/bin/sudo
linux-ug79:~ #
I will reboot the system (to make sure) and try again to become root with su + Password
After rebooting the system
IT WORKS!!!
What happened and why?
Thanks to everyone involved.
I will refrain from installing VBox again
And why didn’t you tell that?
Those errors about “will not give away s-bits on an insecure path” imply that the ownership/permissions of /usr/bin/ or /usr/ itself are wrong too.
Therefore chkstat doesn’t add the s bit to those files.
And you should really fix that and run “chkstat” again, because as you can see, it’s not only su and sudo that have wrong permissions and therefore won’t work.
So please post the output of:
ls -la /usr
Here is the output
linux-ug79:/home/jcaser # chkstat --system
Checking permissions and ownerships - using the permissions files
/etc/permissions
/etc/permissions.easy
/etc/permissions.d/mail-server
/etc/permissions.d/postfix
/etc/permissions.local
setting /usr/lib/utempter/utempter to root:utmp 2755. (wrong permissions 0775)
/usr/lib/utempter/utempter: will not give away s-bits on an insecure path
setting /usr/bin/at to root:trusted 4755. (wrong permissions 0775)
/usr/bin/at: will not give away s-bits on an insecure path
setting /usr/bin/crontab to root:trusted 4755. (wrong permissions 0775)
/usr/bin/crontab: will not give away s-bits on an insecure path
setting /usr/bin/gpasswd to root:shadow 4755. (wrong permissions 0775)
/usr/bin/gpasswd: will not give away s-bits on an insecure path
setting /usr/bin/newgrp to root:root 4755. (wrong permissions 0775)
/usr/bin/newgrp: will not give away s-bits on an insecure path
setting /usr/bin/passwd to root:shadow 4755. (wrong permissions 0775)
/usr/bin/passwd: will not give away s-bits on an insecure path
setting /usr/bin/chfn to root:shadow 4755. (wrong permissions 0775)
/usr/bin/chfn: will not give away s-bits on an insecure path
setting /usr/bin/chage to root:shadow 4755. (wrong permissions 0775)
/usr/bin/chage: will not give away s-bits on an insecure path
setting /usr/bin/chsh to root:shadow 4755. (wrong permissions 0775)
/usr/bin/chsh: will not give away s-bits on an insecure path
setting /usr/bin/expiry to root:shadow 4755. (wrong permissions 0775)
/usr/bin/expiry: will not give away s-bits on an insecure path
setting /usr/bin/sudo to root:root 4755. (wrong permissions 4775)
/usr/bin/sudo: will not give away s-bits on an insecure path
setting /usr/bin/eject to root:audio 4755. (wrong permissions 0775)
/usr/bin/eject: will not give away s-bits on an insecure path
setting /usr/bin/fusermount to root:trusted 4755. (wrong permissions 0775)
/usr/bin/fusermount: will not give away s-bits on an insecure path
setting /usr/lib/gnome-pty-helper to root:utmp 2755. (wrong permissions 0775)
/usr/lib/gnome-pty-helper: will not give away s-bits on an insecure path
setting /usr/bin/v4l-conf to root:video 4755. (wrong permissions 0775)
/usr/bin/v4l-conf: will not give away s-bits on an insecure path
setting /usr/bin/wall to root:tty 2755. (wrong permissions 0775)
/usr/bin/wall: will not give away s-bits on an insecure path
setting /usr/bin/write to root:tty 2755. (wrong permissions 0775)
/usr/bin/write: will not give away s-bits on an insecure path
setting /usr/lib/libgnomesu/gnomesu-pam-backend to root:root 4755. (wrong permissions 0775)
/usr/lib/libgnomesu/gnomesu-pam-backend: will not give away s-bits on an insecure path
setting /usr/bin/fileshareset to root:root 4755. (wrong permissions 0775)
/usr/bin/fileshareset: will not give away s-bits on an insecure path
setting /usr/lib/polkit-1/polkit-agent-helper-1 to root:root 4755. (wrong permissions 0775)
/usr/lib/polkit-1/polkit-agent-helper-1: will not give away s-bits on an insecure path
setting /usr/bin/pkexec to root:root 4755. (wrong permissions 0775)
/usr/bin/pkexec: will not give away s-bits on an insecure path
setting /usr/sbin/lockdev to root:lock 2755. (wrong permissions 0775)
/usr/sbin/lockdev: will not give away s-bits on an insecure path
setting /usr/bin/su to root:root 4755. (wrong permissions 4775)
/usr/bin/su: will not give away s-bits on an insecure path
setting /usr/bin/mount to root:root 4755. (wrong permissions 0775)
/usr/bin/mount: will not give away s-bits on an insecure path
setting /usr/bin/umount to root:root 4755. (wrong permissions 0775)
/usr/bin/umount: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
linux-ug79:/home/jcaser # ls -la /usr
linux-ug79:/home/jcaser # ls -la /usr
total 412
drwxr-xr-x 13 root root 4096 may 17 2012 .
drwxr-xr-x 24 root root 4096 dic 13 07:08 …
drwxrwxr-x 2 root root 102400 dic 13 07:02 bin
drwxrwxr-x 2 root root 4096 sep 27 22:24 games
drwxrwxr-x 135 root root 12288 dic 13 07:00 include
drwxrwxr-x 133 8070 9999 90112 dic 13 07:01 lib
drwxrwxr-x 182 root root 143360 dic 13 07:02 lib64
drwxrwxr-x 11 root root 4096 nov 6 20:58 local
drwxrwxr-x 2 root root 20480 dic 13 07:02 sbin
drwxrwxr-x 283 root root 12288 dic 13 06:54 share
drwxrwxr-x 6 root root 4096 dic 9 14:23 src
lrwxrwxrwx 1 root root 10 nov 6 20:58 tmp → …/var/tmp
drwxrwxr-x 5 root root 4096 nov 6 20:58 X11R6
drwxrwxr-x 5 root root 4096 nov 6 20:58 x86_64-suse-linux
Yeah, this is all wrong. The permissions should be “drwxr-xr-x” for all the subdirectories.
And lib even has a very strange, non-existing owner. (8070:9999)
I guess the best thing to do is to reinstall the “filesystem” package, that should fix all those permissions:
sudo zypper in -f filesystem
And then run “chkstat” again.
On 2013-12-13 12:46, wolfi323 wrote:
> Therefore chkstat doesn’t add the s bit to those files.
You are missing “–set”:
chkstat --system --set
as root.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
“–set” is default in --system mode.
Here the output of the commands
linux-ug79:/home/jcaser # zypper in -f filesystem
Obteniendo los metadatos del repositorio ‘RPMs_Downloads’ …[hecho]
Obteniendo los metadatos del repositorio ‘openSUSE-13.1-Update-Debug’ …[hecho]
Construyendo el caché del repositorio ‘openSUSE-13.1-Update-Debug’ …[hecho]
Obteniendo los metadatos del repositorio ‘openSUSE-13.1-Update’ …[hecho]
Construyendo el caché del repositorio ‘openSUSE-13.1-Update’ …[hecho]
Obteniendo los datos del repositorio…
Leyendo los paquetes instalados…
Forzando la instalación de ‘filesystem-13.1-3.1.2.x86_64’ del repositorio ‘qucs’.
Resolviendo dependencias…
El siguiente paquete va a ser reinstalado:
filesystem
1 paquete a reinstalar.
Tamaño total a descargar: 67,7 KiB. No se utilizará ni liberará espacio adicional luego de la operación.
¿Desea continuar? [s/n/? mostrar todas las opciones] (s): s
Descargando paquete filesystem-13.1-3.1.2.x86_64 (1/1), 67,7 KiB ( 0 B desempaquetado)
Obteniendo: filesystem-13.1-3.1.2.x86_64.rpm …[hecho]
(1/1) Instalando filesystem-13.1-3.1.2 …[hecho]
linux-ug79:/home/jcaser # chkstat --system
Checking permissions and ownerships - using the permissions files
/etc/permissions
/etc/permissions.easy
/etc/permissions.d/mail-server
/etc/permissions.d/postfix
/etc/permissions.local
setting /usr/lib/utempter/utempter to root:utmp 2755. (wrong permissions 0775)
/usr/lib/utempter/utempter: will not give away s-bits on an insecure path
setting /usr/bin/at to root:trusted 4755. (wrong permissions 0775)
setting /usr/bin/crontab to root:trusted 4755. (wrong permissions 0775)
setting /usr/bin/gpasswd to root:shadow 4755. (wrong permissions 0775)
setting /usr/bin/newgrp to root:root 4755. (wrong permissions 0775)
setting /usr/bin/passwd to root:shadow 4755. (wrong permissions 0775)
setting /usr/bin/chfn to root:shadow 4755. (wrong permissions 0775)
setting /usr/bin/chage to root:shadow 4755. (wrong permissions 0775)
setting /usr/bin/chsh to root:shadow 4755. (wrong permissions 0775)
setting /usr/bin/expiry to root:shadow 4755. (wrong permissions 0775)
setting /usr/bin/sudo to root:root 4755. (wrong permissions 4775)
setting /usr/bin/eject to root:audio 4755. (wrong permissions 0775)
setting /usr/bin/fusermount to root:trusted 4755. (wrong permissions 0775)
setting /usr/lib/gnome-pty-helper to root:utmp 2755. (wrong permissions 0775)
setting /usr/bin/v4l-conf to root:video 4755. (wrong permissions 0775)
setting /usr/bin/wall to root:tty 2755. (wrong permissions 0775)
setting /usr/bin/write to root:tty 2755. (wrong permissions 0775)
setting /usr/lib/libgnomesu/gnomesu-pam-backend to root:root 4755. (wrong permissions 0775)
/usr/lib/libgnomesu/gnomesu-pam-backend: will not give away s-bits on an insecure path
setting /usr/bin/fileshareset to root:root 4755. (wrong permissions 0775)
setting /usr/lib/polkit-1/polkit-agent-helper-1 to root:root 4755. (wrong permissions 0775)
/usr/lib/polkit-1/polkit-agent-helper-1: will not give away s-bits on an insecure path
setting /usr/bin/pkexec to root:root 4755. (wrong permissions 0775)
setting /usr/sbin/lockdev to root:lock 2755. (wrong permissions 0775)
setting /usr/bin/su to root:root 4755. (wrong permissions 4775)
setting /usr/bin/mount to root:root 4755. (wrong permissions 0775)
setting /usr/bin/umount to root:root 4755. (wrong permissions 0775)
ERROR: not all operations were successful.
It seems there are still errors
This is the results
linux-ug79:/home/jcaser # chkstat --system --set
Checking permissions and ownerships - using the permissions files
/etc/permissions
/etc/permissions.easy
/etc/permissions.d/mail-server
/etc/permissions.d/postfix
/etc/permissions.local
setting /usr/lib/utempter/utempter to root:utmp 2755. (wrong permissions 0775)
/usr/lib/utempter/utempter: will not give away s-bits on an insecure path
setting /usr/lib/libgnomesu/gnomesu-pam-backend to root:root 4755. (wrong permissions 0775)
/usr/lib/libgnomesu/gnomesu-pam-backend: will not give away s-bits on an insecure path
setting /usr/lib/polkit-1/polkit-agent-helper-1 to root:root 4755. (wrong permissions 0775)
/usr/lib/polkit-1/polkit-agent-helper-1: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
Still some errors
cheers /saludos (la madre que le pario al problema)
Yes, those are still not ok. The rest should be now.
I would recommend to reinstall the packages containing those files:
sudo zypper in -f libutempter0 libgnomesu polkit
This will also call chkstat, so everything should be fine then.
But for verification, run yourself “chkstat --system” a last time, it should not give any output anymore.
Regarding VirtualBox, I have no idea why that happened, but why not install the virtualbox included in openSUSE? I never had any problem with this one.
You’d need the packages “virtualbox”, “virtualbox-qt” and one of the “virtualbox-host-kmp-*” packages, depending on your kernel (presumaby “virtualbox-host-kmp-desktop”).
I did it
linux-ug79:/home/jcaser # chkstat --system --set
linux-ug79:/home/jcaser #
Everytrhing is fine now
Perhaps one day I will install virtual Box
Thanks to you and to everyone involved
juan Carlos
On 2013-12-13 14:06, wolfi323 wrote:
>
> robin_listas;2607840 Wrote:
>> On 2013-12-13 12:46, wolfi323 wrote:
>>> Therefore chkstat doesn’t add the s bit to those files.
>>
>> You are missing “–set”:
>>
> “–set” is default in --system mode.
No, it is not. System does whatever the variable CHECK_PERMISSIONS in
“/etc/sysconfig/security” says. It should be “set”, but it might not.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Wrong.
If CHECK_PERMISSIONS is not set, it defaults to “set”.
And CHECK_PERMISSION is not at all contained in /etc/sysconfig/security on a fresh installation.
And if you look at jcaser1948’s output you should see that the permissions have been set without specifying “–set”…
Just try it yourself if you don’t believe me.
On 2013-12-13 18:16, wolfi323 wrote:
>
> robin_listas;2607904 Wrote:
>> No, it is not. System does whatever the variable CHECK_PERMISSIONS in
>> “/etc/sysconfig/security” says. It should be “set”, but it might not.
>>
> Wrong.
> If CHECK_PERMISSIONS is not set, it defaults to “set”.
All variables have defaults.
> And CHECK_PERMISSION is not at all contained in /etc/sysconfig/security
> on a fresh installation.
The man page says it checks that variable. The meaning of “–system” is
that it checks that system variable. You can not make assumptions about
it on a system you don’t know how much has been tampered with.
> And if you look at jcaser1948’s output you should see that the
> permissions have been set without specifying “–set”…
No, I see that it finally worked when he set it (–set), the second time.
> Just try it yourself if you don’t believe me.
I did, time ago. That’s why my notes specify --set, I tried both ways.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Yes, and for this the default is “set” so there’s no need to specify “–set”.
> And CHECK_PERMISSION is not at all contained in /etc/sysconfig/security
> on a fresh installation.
The man page says it checks that variable. The meaning of “–system” is
that it checks that system variable. You can not make assumptions about
it on a system you don’t know how much has been tampered with.
Correct, but I would think if the OP would have added that variable to /etc/sysconfig/security himself, he wouldn’t have needed any help to fix his problem at all…
> And if you look at jcaser1948’s output you should see that the
> permissions have been set without specifying “–set”…
No, I see that it finally worked when he set it (–set), the second time.
No, when he added “–set” there were only 3 wrong permissions left.
The others were fixed by “chkstat --system” without “–set”…
And those 3 didn’t get fixed by “–set” either.
> Just try it yourself if you don’t believe me.
I did, time ago. That’s why my notes specify --set, I tried both ways.
And I did just before I wrote this.
On 2013-12-13 14:56, jcaser1948 wrote:
> Here the output of the commands
Please use code tags for printouts and commands (the ‘#’ button).
Posting in
Code Tags - A Guide
And please post the commands in English. wolfi323 has missed an
important detail because of that.
When the system language is not English, you should do,
in order to post here, like this:
minas-tirith:~ # LANG=en_US.UTF-8 zypper info kvm
Loading repository data...
Warning: Repository 'openSUSE-11.4-Update' appears to outdated. Consider
using a different mirror or server.
Reading installed packages...
or this:
minas-tirith:~ # LANG=C zypper info kvm
Loading repository data...
Warning: Repository 'openSUSE-11.4-Update' appears to outdated. Consider
using a different mirror or server.
Reading installed packages...
^C
That way we can all read it, regardless of local languages of sender and
reader. It is not a permanent change, it only applies to one command.
> Forzando la instalación de ‘filesystem-13.1-3.1.2.x86_64’ del
> repositorio ‘qucs’.
Translation: “Forcing installation of ‘filesystem-13.1-3.1.2.x86_64’
from repository ‘gucs’”. What the h**k is that repository? That package
should come from repository “repo-oss”.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Which detail do you mean?
That repo where “filesystem” came from?
> Forzando la instalación de ‘filesystem-13.1-3.1.2.x86_64’ del
> repositorio ‘qucs’.
Translation: “Forcing installation of ‘filesystem-13.1-3.1.2.x86_64’
from repository ‘gucs’”. What the h**k is that repository? That package
should come from repository “repo-oss”.
I just had a look. “filesystem-13.1-3.1.2” is exactly the version from repo-oss.
So I guess that’s ok…
@jcaser1948:
Maybe you could post the output of “zypper lr -d” to be sure…
OTOH filesystem doesn’t contain much anyway, except for all those system directories.
So I guess the repo is not too critical.
On 2013-12-13 23:56, wolfi323 wrote:
> robin_listas;2608048 Wrote:
> Which detail do you mean?
> That repo where “filesystem” came from?
Yep. Not your fault 
> I just had a look. “filesystem-13.1-3.1.2” is exactly the version from
> repo-oss.
> So I guess that’s ok…
Version number is the same, I know. But the contents are unknown yet.
>
> @jcaser1948:
> Maybe you could post the output of “zypper lr -d” to be sure…
Right
>
> OTOH filesystem doesn’t contain much anyway, except for all those system
> directories.
> So I guess the repo is not too critical.
If it is an unknown source, it could have different permissions for its
own reason. It could explain things.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
WRT the VB ( VirtualBox ) rpm VirtualBox-4.3-4.3.4_91027_openSUSE123-1.x86_64.rpm
direct from virtualbox.org, the first time I ever installed VB quite some time ago,
AFAIK, I did so with an rpm direct from their website. I didn’t have the type of
problem we’ve been discussing in this thread. Fairly early in the course of this
thread, I’d looked at the contents of the particular rpm in question here. Although
it does use the chcon command, it didn’t look as if the install should cause a problem.
BTW, the name of the rpm was intended to indicate that it applies to oS 12.3
through oS 13.1.
To test the idea that the install shouldn’t cause a problem, I:
- Did a completely new install of 13.1 in a separate partition.
- Backed up the contents of the root partition of the new install.
- Installed VB from the downloaded rpm, along with a lib on which
that form of VB depends, and since the install wanted to build the
VB modules, installed gcc and related. - Since the VB install creates a vboxusers group which Users of VB
are expected to be in, added a standard User account to that group. - Ran VB, worked with it, and was able to use VB as usual.
- Ran chkstat --system --warn which effectively didn’t like that the
VB install had used chcon, but there were no other complaints. - Wrote, tested, ran a program to do a detailed comparison of file
permissions of ALL files in the root partition of the new install,
against the backup copy. NO permissions of files not installed by
the rpm, were changed by the install.
I suppose there may be an outside chance that under some very different
conditions, something really strange might happen, but the install
scripts don’t necessarily look particularly error prone.
I’ve certainly sometimes done something like the following. Been busy,
made various changes to a system, quickly. Things seemingly worked afterwards.
Sometime later I installed something, after which I discovered a problem.
I expected the most recent change I made had caused the problem, but eventually
realized it was a side affect of the previous changes, an affect I hadn’t noticed
before.
Maybe that’s what happened here.