Description of problem: $ machinectl shell Failed to get shell PTY: Message recipient disconnected from message bus without replying Version-Release number of selected component (if applicable): systemctl --version systemd 225 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This error is caused by SELinux: Aug 31 07:47:13 rawhide-virt audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Aug 31 07:47:13 rawhide-virt audit[485]: AVC avc: denied { read write } for pid=485 comm="dbus-daemon" path="/dev/ptmx" dev="devtmpfs" ino=1137 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file permissive=0
On my other machine (rawhide as well), I'm also getting Aug 31 11:28:18 rawhide audit[1865]: AVC avc: denied { transition } for pid=1865 comm="(sh)" path="/usr/bin/bash" dev="sda3" ino=84406 scontext=system_u:system_r:init_t:s0 tcontext=unconfined Aug 31 11:28:18 rawhide systemd[1865]: container-shell: Failed at step EXEC spawning /bin/sh: Permission denied
(In reply to Jan Synacek from comment #2) > On my other machine (rawhide as well), I'm also getting > > Aug 31 11:28:18 rawhide audit[1865]: AVC avc: denied { transition } for > pid=1865 comm="(sh)" path="/usr/bin/bash" dev="sda3" ino=84406 > scontext=system_u:system_r:init_t:s0 tcontext=unconfined > Aug 31 11:28:18 rawhide systemd[1865]: container-shell: Failed at > step EXEC spawning /bin/sh: Permission denied Yes, that's a problem which we will need to discuss. We will need to make it working to reflect SELinux users.
The point is we have pam_selinux here so it requires "transition" perms. Also not sure if it reflect MCS/MLS range. Need to do more testing.
Dan, Dominick any chance you have been playing with that?
what does machinectl shell supposed to do? Start a shell within a container or VM?
time->Fri Sep 11 15:28:02 2015 type=USER_AVC msg=audit(1441999682.293:4830): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission stop for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' I am seeing the following when I execute that command on rawhide. It looks like the SELinux/systemd code is broken. We could probably add a transition from init_t to unconfined_t. systemd should probably be maching the label of the pid 1 on a container.
https://github.com/fedora-selinux/selinux-policy/commit/c7d98ff11daa0743f46c1500196ef1eae9b79f74
It still fails to work correctly [darrell@localhost ~]$ machinectl shell Failed to get shell PTY: Message recipient disconnected from message bus without replying selinux-policy.noarch 3.13.1-148.fc24 @koji systemd.x86_64 226-3.fc24 @koji
There would be a transition. Could you attach AVCs?
Created attachment 1076987 [details] journalctl log
Created attachment 1079458 [details] journalctl log again
With selinux-policy-3.13.1-150.fc24 there is still no shell
https://github.com/fedora-selinux/selinux-policy/commit/53c0f7b97b0165f46276ad20b28d694d6b5119f2 commit 53c0f7b97b0165f46276ad20b28d694d6b5119f2 Author: Miroslav Grepl <mgrepl> Date: Tue Oct 13 10:12:47 2015 +0200 Allow systemd_machined_t to send dbus msgs to all users and read/write /dev/ptmx to make 'machinectl shell' working correctly.
Created attachment 1082614 [details] Latest messages
Still fails to work Failed to get shell PTY: No such file or directory Latest log attached
I believe this option is gone with the kdbus removal from rawhide. Looked in the man page and didn't see it any more.
This bug probably still is valid - "machinectl shell" is no longer a valid subcommand, but "machinectl login" produces the same error on F23. Reported as BZ #1310464
Confirming the problem on Fedora 25. Only setting selinux in permissive mode I could use "machinectl shell" command SELinux is preventing (sh) from lock access on the file /var/log/lastlog. Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:lastlog_t:s0 Target Objects /var/log/lastlog [ file ] Source (sh) Source Path (sh) Port <Unknown> Host host Source RPM Packages Target RPM Packages Policy RPM <Unknown> Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Platform Linux host 4.10.5-200.fc25.x86_64 #1 SMP Wed Mar 22 20:37:08 UTC 2017 x86_64 x86_64 Alert Count 1 First Seen 2017-03-29 17:51:11 CEST Last Seen 2017-03-29 17:51:11 CEST Raw Audit Messages type=AVC msg=audit(1490802671.895:358): avc: denied { lock } for pid=13847 comm="(sh)" path="/var/log/lastlog" dev="sdb2" ino=20948 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:lastlog_t:s0 tclass=file permissive=1 Hash: (sh),init_t,lastlog_t,file,lock selinux-policy.noarch 3.13.1-225.11.fc25
Confirmed With SELinux in enforcing mode and default targeted policy, running # whoami root # machinectl shell --uid=root Failed to get shell PTY: Access denied even when run as root (if not password prompt will escalate if I understand correctly). Switching SELinux in permissive mode with setenforce 0 makes it work. It's not a solution it's just to point to SELinux as the source of the problem. audit logs are now showing any AVC, even if build with donotautid disabled (semodule -BD), which puzzles me. Strace-ing systemd-machined shows 8800 open("/dev/ptmx", O_RDWR|O_NOCTTY|O_CLOEXEC) = 8 8800 ioctl(8, TIOCSPTLCK, [0]) = 0 8800 ioctl(8, TIOCGPTN, [14]) = 0 8800 open("/dev/pts/14", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EACCES (Permission denied) 8800 close(8) = 0 8800 sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\3\1\1\26\0\0\0B\0\0\0O\0\0\0\5\1u\0\3\0\0\0\6\1s\0\6\0\0\0:1.164\0\0\4\1s\0'\0\0\0org.freedesktop.DBus.Error.AccessDenied\0\10\1g\0\1s\0\0", iov_len=96}, {iov_base="\21\0\0\0Permission denied\0", iov_len=22}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 118 So it could be that systemd_machined_t cannot access user_devpts_t
Still present in F26.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still the same problem on F27: $ machinectl login Failed to get login PTY: Access denied $ sudo machinectl login Failed to get login PTY: Access denied $ sudo setenforce 0 $ machinectl login Connected to the local host. Press ^] three times within 1s to exit session. ... Someone with privileges please bump the version on this bug.
Does anyone care that one Red Hat-championed product (SELinux) has now been breaking key functionality of another Red Hat-funded and championed product (systemd) for THREE releases now?
Correction: FOUR Fedora releases.
I (we) care. I'll contact systemd folks and we try to make it working.
It is still broken on F29: # machinectl login Failed to get login PTY: Access denied USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/container-getty@.service" cmdline="/usr/lib/systemd/systemd-machined" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:getty_unit_file_t:s0 tclass=service permissive=0 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' # machinectl shell Failed to get shell PTY: Message recipient disconnected from message bus without replying ---- time->Wed Nov 21 23:55:45 2018 type=AVC msg=audit(1542840945.792:1746): avc: denied { read write } for pid=987 comm="dbus-daemon" path="/dev/pts/9" dev="devpts" ino=12 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=0 Please update the version of this bug....
> I (we) care. SIX Fedora releases.
Following PRs should fix the issue: https://github.com/fedora-selinux/selinux-policy/pull/255 https://github.com/fedora-selinux/selinux-policy-contrib/pull/99
*** Bug 1416540 has been marked as a duplicate of this bug. ***
selinux-policy-3.14.2-53.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bf377d92c7
selinux-policy-3.14.2-53.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bf377d92c7
selinux-policy-3.14.2-53.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
hi, on a fedora 31 workstation I have the same problems, so its not really fixed I am afraid. I have set the systemd_machined_d to permissive and most things work except machinectl shell or login. # machinectl login kdc Failed to get login PTY: Remote peer disconnected If I try that I get this in auditlogd: # ausearch -m avc -ts recent ---- time->Sat Feb 29 13:57:22 2020 type=AVC msg=audit(1582981042.746:349): avc: denied { read } for pid=6892 comm="(sd-openpt)" name="ptmx" dev="tmpfs" ino=95850 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=lnk_file permissive=1 ---- time->Sat Feb 29 13:57:22 2020 type=AVC msg=audit(1582981042.746:350): avc: denied { open } for pid=6892 comm="(sd-openpt)" path="/dev/pts/ptmx" dev="devpts" ino=2 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=1 ---- time->Sat Feb 29 13:57:22 2020 type=AVC msg=audit(1582981042.748:351): avc: denied { write } for pid=6896 comm="(sd-buscntr)" name="system_bus_socket" dev="tmpfs" ino=98837 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=sock_file permissive=1 ---- time->Sat Feb 29 13:57:22 2020 type=AVC msg=audit(1582981042.748:352): avc: denied { connectto } for pid=6896 comm="(sd-buscntr)" path="/run/dbus/system_bus_socket" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=1 ---- time->Sat Feb 29 13:57:22 2020 type=AVC msg=audit(1582981042.750:353): avc: denied { read write } for pid=1084 comm="dbus-broker" path="/dev/pts/ptmx" dev="devpts" ino=2 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=0 and the only way to enter the console of the container is setenforce 0, then it works. So if anyone is still interested in fixing this, ..., :-)
another problem, probably related, with the same permissive domain, I cannot access the journal of the container. If I set selinux in permissive mode globally, then it works: # semodule -l | grep permissive permissive_systemd_machined_t permissivedomains # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 32 # journalctl -M centos1 Failed to open root directory: Remote peer disconnected # ausearch -m avc -ts recent time->Wed Mar 4 19:09:08 2020 type=AVC msg=audit(1583345348.434:352): avc: denied { search } for pid=8879 comm="systemd-machine" name="5997" dev="proc" ino=117733 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=1 ---- time->Wed Mar 4 19:09:08 2020 type=AVC msg=audit(1583345348.434:353): avc: denied { read } for pid=8879 comm="systemd-machine" name="mnt" dev="proc" ino=123349 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=lnk_file permissive=1 ---- time->Wed Mar 4 19:09:08 2020 type=AVC msg=audit(1583345348.436:354): avc: denied { read } for pid=1098 comm="dbus-broker" path="/" dev="dm-1" ino=4104961 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_machined_var_lib_t:s0 tclass=dir permissive=0 # setenforce 0 # journalctl -M centos1 -- Logs begin at Sun 2020-03-01 22:32:25 CET, end at Wed 2020-03-04 19:05:05 CET. -- Mar 01 22:32:25 centos8 systemd-journald[17]: Journal started Mar 01 22:32:25 centos8 systemd-journald[17]: Runtime journal (/run/log/journal/1b019ef3b8794cd0abf27514f0e5cc0a) is 8.0M, max 794.1M, 786.1M free. Mar 01 22:32:25 centos8 systemd[1]: Starting Flush Journal to Persistent Storage... Mar 01 22:32:25 centos8 systemd-journald[17]: Time spent on flushing to /var is 1.121ms for 3 entries. ....
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I am currently experiencing this issue in Fedora 34. For me, this was also related to: https://bugzilla.redhat.com/show_bug.cgi?id=1760146 After a while of adjusting the SELinux policy, I was eventually able to get nspawn and machinectl working properly, including the shell and login commands. I am attaching the SELinux policy changes that I made to this bug for further investigation.
Created attachment 1821667 [details] SELinux Policy Changes for machinectl SELinux policy changes for machinectl shell and login to function properly. Source for custom policy module that fixes the issue.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days