Comment 130 for bug 1197395

(In reply to Clement Lefebvre from comment #61)
> In your patch you're checking for the ownership of the runtime dir. That's a
> good idea but I don't think it's enough.
>
> For instance we're observing a conflict on /run/user/1000/dconf/user when we
> run dconf apps as root.

But these shouldn't use that runtime dir in the first place. As soon as you have a root process scribbling over your user's runtime dir, you have lost. That's precisely what we want to avoid here, isn't it?

> The problem is with the "user" file created by dconf in
> /run/user/1000/dconf/. When it exists (it doesn't always since it's removed
> when dconf no longer needs it), it either belongs to 1000, or to root.

It should never belong to root.

> I think Colin is right here, we need to check the user id and categorically
> forbid different users (root included) to share the same runtime path.

That's what this patch is supposed to do. What would be the scenario where that fails?

Note that there are still cases where this would fail. For example, if you use sudo (without -i), that doesn't involve PAM, but might (depending on the config) keep the $XDG_* variables around for the process you run through it. That doesn't happen on the default sudo configuration, but you can tell it to keep the whole environment.