On 12/05/2014 08:49 AM, Peter Lemenkov wrote: > 2014-12-05 16:25 GMT+03:00 Lennart Poettering <lenn...@poettering.net>: >> On Fri, 05.12.14 16:58, Peter Lemenkov (lemen...@gmail.com) wrote: >> >>> Ok, now I've got something. Here is a a diff between good (1st, >>> commandline) and bad (2nd, systemd service) sessions: >>> >>> * https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff >>> >>> More specifically I found these pieces interesting: >>> >>> * >>> https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258 >>> >>> Notice "open("/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES >>> (Permission denied)" when started as systemd service: >>> >>> * >>> https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700 >>> >>> Notice "unlink("/run/systemd/journal/dev-log") = -1 EACCES >>> (Permission denied)" followed by "bind(7, {sa_family=AF_LOCAL, >>> sun_path="/run/systemd/journal/dev-log"}, 30) = -1 EADDRINUSE (Address >>> already in use)". >>> >>> Looks like systemd-nspawn either doesn't mounts (bind mounts) a >>> necessary devices or doesn't create them properly. >> Hmm, do you have SELinux enabled and in enforcing mode? >> >> nspawn mounts a tmpfs to /run, very early on, before invoking the >> first binary, it should definitely be writable. > Yes! That's a SELinux denial. I'm sorry for bothering you and for not > trying switching selinux off and on again - I actually thought that > all the SELinux issues are gone already. > > In case you're interested - here is a dump of dmesg | audit2allow: > > > #============= getty_t ============== > allow getty_t devpts_t:chr_file { write getattr setattr read open ioctl }; > allow getty_t rpm_var_lib_t:file open; > allow getty_t tmpfs_t:chr_file read; > > #============= syslogd_t ============== > allow syslogd_t tmpfs_t:chr_file { read write ioctl open }; > allow syslogd_t tmpfs_t:dir { write create add_name }; > allow syslogd_t tmpfs_t:file { create setattr }; > allow syslogd_t tmpfs_t:sock_file write; > > #============= systemd_logind_t ============== > allow systemd_logind_t tmpfs_t:filesystem mount; > allow systemd_logind_t tmpfs_t:sock_file write; > allow systemd_logind_t user_tmp_t:dir mounton; > > #============= systemd_sysctl_t ============== > > #!!!! This avc can be allowed using the boolean 'domain_kernel_load_modules' > allow systemd_sysctl_t kernel_t:system module_request; > > #========================================== > > And here is a full explanation: > > https://paste.fedoraproject.org/156932/78730514/ > > I'll try to open a bug reports in RHBZ on each issue found. > Are these processes running within a systemd-nspawn container? If so we really need to do what we did for docker and get all of the contents within a container to run with a single label, And potentially get all of the content within a container to run with a single label.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
