On Wed, 08.10.14 14:44, Maciej Wereski (m.were...@partner.samsung.com) wrote:
Hello,
Lately I've been working on updating systemd (currently 208) in Tizen. One
of problems we've stumbled upon was with user@.service failing. Problem
was on SMACK-enabled system, caused by 1c231f5 (logind: make
$XDG_RUNTIME_DIR a per-user tmpfs).
When $XDG_RUNTIME_DIR is mounted it inherits logind label, which in turn
forbid users to access theirs directories.
One solution would be to add if (use_smack())
mount(...smackfsroot=*...) in logind-user.c,
but it would also require to add CAP_MAC_ADMIN to
systemd-logind.service.
This sounds like an OK solution to me.
Another solution would be to remove mounting logic from logind-user.c
completely and add run-user@.mount. user@.service would gain following
lines:
Requires=run-user@%I.mount
After=run-user@%I.mount
Unfortunately, currently it's not possible.
First problem is that unit isn't named after path, so that requirement
needs to be removed first.
Second - we don't have gid, but it doesn't seem to be an issue, as mode is
set to 0700.
Then, in Tizen we could just add smackfsroot to options. Alternatively
SmackLabel= option could be added for mount units, which would
automatically append smackfsroot to options, when SMACK is enabled.
How should we solve this issue?
systemd .mount units are great for many things, but I am not sure I
would bother with them in this case. I mean, they have the advantage
of being integrated in the full dependency logic between mounts and
devices and stuff, and that they can be introspected, enumerated,
disabled, individually mounted and so on. But in this case nothing of
this really matters, the mounting is always fully automatic, and it's
a virtual file system, not backed by anything. THus, I'd really stick
to raw mount() calls for this.
I understand that this is not that great on smack systems, but that's
how it is then...
Maybe a better option would be to implement a mount wrapper call in
util.c or so that takes the same arguments as mount() but internally
does the SMACK logic so that we don't have to litter the smack code
all over the place? THis would allow us to unify the smack related
code in logind and PID1?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
