Bug 1388359

Applicable also for RHEL7.3 without reasonable workaround (ChrootDirectory none  will not work in openssh-6.6). This setup will be broken with last openssh update.

The same patch as in the original bug applies also for RHEL7.3 and fixes the issue. I would like to see this fixed as soon as possible or at least document as a known bug (unfortunately we get to know this bug quite late).

+++ This bug was initially created as a clone of Bug #1386755 +++

Description of problem:

If logged in via sshd, root can not access some files, that do not have o+r or belong too root:

[root@c1 ~]# cat /etc/shadow
cat: /etc/shadow: Keine Berechtigung
[root@c1 ~]# ls -la /var/log/exim/
ls: Öffnen von Verzeichnis /var/log/exim/ nicht möglich: Keine Berechtigung
[root@c1 ~]# id
uid=0(root) gid=0(root) Gruppen=0(root)
[root@c1 ~]#

BUT, if logged in via a Konsole, root is root and can access those files.

Actual results:

no root functionality. Root is threated as any other normal user account.

Expected results:

beeing root again.

--- Additional comment from  on 2016-10-21 10:48:08 CEST ---

Sources: 

http://marius.bloggt-in-braunschweig.de/2016/10/20/update-fedora-openssh-alarm-nicht-updaten-auf-7-2p2-6/
https://marius.bloggt-in-braunschweig.de/2016/10/19/fedora-openssh-alarm-nicht-updaten-auf-7-2p2-6/


Working Downgrade methodes :

1. Download the previouse version of the three updates packages from : 

http://koji.fedoraproject.org/koji/buildinfo?buildID=756836

best to /tmp/ on the server you need to regain controll over. I suggest version 7.2p2-3 .

2. as defective root user do : 

-- CHANGE THE TIME before your execute it --

echo "41 10 * * * root /usr/bin/rpm -U --force /tmp/openssh*rpm > /tmp/log; rm -f /etc/cron.d/onetime" > /etc/cron.d/onetime

3. logoff and wait for it to happen
4. login again.. done

--- Additional comment from  on 2016-10-21 11:35:34 CEST ---


Yes, chroot is enabled, but not for root.

--------------------------------
[...]
ChrootDirectory /opt/root/
Match user root
 	ChrootDirectory /

--- Additional comment from  on 2016-10-21 11:37:41 CEST ---

Capabilities and Groupinfos are gone ( as expected :) )


NONE WORKING:

[root@XXX ~]# capsh --print
Current: =
Bounding set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=


WORKING: 

[root@XXXX ~]# capsh --print
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

--- Additional comment from Jakub Jelen on 2016-10-21 11:47:14 CEST ---

Thank you for the additional information.

> Match user root
>  	ChrootDirectory /

This is wrong. You should use "ChrootDirectory none" to avoid chroot. Because otherwise the chroot operation is executed on the / . This should be noop, but evidently is not.
I will investigate why does it behave this way. It never came to my mind to do chroot on / (and not sure if we want to support it).

--- Additional comment from  on 2016-10-21 12:00:09 CEST ---

with "none" as chrootdirectory 

- capabilities and groups are back
- access is back

Seems to work.