[systemd-devel] [PATCH] Reset the context of /run/user/UID to the default. Bug #1097901.

Miroslav Grepl mgrepl at redhat.com
Fri May 16 08:32:36 PDT 2014


On 05/15/2014 07:12 PM, Lennart Poettering wrote:
> On Thu, 15.05.14 18:54, Miroslav Grepl (mgrepl at redhat.com) wrote:
>
>>>>           u->runtime_path = p;
>>>>           return 0;
>>>> @@ -423,7 +424,9 @@ int user_start(User *u) {
>>>>           log_debug("New user %s logged in.", u->name);
>>>>           /* Make XDG_RUNTIME_DIR */
>>>> +        label_init("/var/run/user");
>>> This looks incorrect. label_init() will be a NOP the second it is
>>> called, and we already call it in logind, with the /etc prefix, hence
>>> we'll only load an incomplete database for the other invocation...
>> Well I thought it too but it was not working without this
>> initialization.
> Sure, some kind of initialization is needed. However, the database is
> loaded statically into the process and once only, then you end up with
> an incomplete database where the bits the other place where we need
> labelling is missing..
>
>
>>>>           r = user_mkdir_runtime_path(u);
>>>> +        label_finish();
>>>>           if (r < 0)
>>>>                   return r;
>>> Why is this necessary, even? I though selinux in the kernel was nowadays
>>> able to take the file name to create into account when applying a label,
>>> so why do we need userspace magic for this?
>> See
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1092059#c0
> WHich doesn't explain why the kernel cannot derive this rule on its
> own. I though the kernel could take the file/dir name to create into
> account nowadays when it is created to find its initial label. But if
> the kernel can do that, why do we need to involve userspace still?
>
> I'd really prefer if we could keep userspace-controlled labelling at a
> minimum. If you ask me we kinda already do too much of it...
Yes. We discuss it in the #1092059 bug again. Basically the problem is 
we are not able to define filename_trans rules how we would need to 
define them.

Thx.
>
> Lennart
>



More information about the systemd-devel mailing list