[systemd-devel] systemd-nspawn at .service is unusable

Daniel J Walsh dwalsh at redhat.com
Mon Dec 8 16:59:40 PST 2014


On 12/05/2014 08:49 AM, Peter Lemenkov wrote:
> 2014-12-05 16:25 GMT+03:00 Lennart Poettering <lennart at poettering.net>:
>> On Fri, 05.12.14 16:58, Peter Lemenkov (lemenkov at 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.




More information about the systemd-devel mailing list