Re: [oe-core][PATCH] sysvinit: create tmpfile dir for x11 domain socket

[Randolph Sapp <rs@ti.com>]

On Wed Oct 15, 2025 at 12:22 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> On Wed Oct 15, 2025 at 9:37 AM CDT, Ross Burton wrote:
>> On 8 Oct 2025, at 00:48, rs@ti.com wrote:
>>> 
>>> From: Randolph Sapp <rs@ti.com>
>>> 
>>> Register a volatile directory entry for the x11 domain socket when not
>>> using systemd. This will make sure the directory is always created with
>>> the correct permissions. Systemd already provides their own tmpfile.d
>>> entry for the same behavior.
>>
>> We discussed this in the patch review call on Monday and concluded that it
>> definitely felt like it should be in the xserver recipe.
>
> Sure.
>

I am a little bummed that we don't want to have symmetry between init system
packages though. Gonna need a gross "VIRTUAL-RUNTIME_init_manager" check
to make sure we don't clash with tmpfiles.d entry.

>>> Currently some x11 related applications will create this directory if it
>>> doesn't already exist, but this is not true for everything. In addition,
>>> if the application in question isn't started as root, it's possible this
>>> directory can be owned by a non-root user. This isn't an issue by
>>> itself, but it can potentially lead to problems in a multi-user
>>> environment.
>>
>> Can you clarify what applications will create this directory and which will
>> not? Surely it’s the responsibility for the xserver to create the sockets?
>>
>> Ross
>
> Forgive me, as it's been quite some time since I initially tested this. I
> believe during testing with the current default xsession managers will create it
> but xwayland sessions will not. Given that systemd has determined they need to
> ship this as a global tmpfiles.d entry I assume there is more nuance to this
> than what I have outlined.
>
> - Randolph

Ah, now I remember, all rootless X sessions also have the capability of
generating this socket directory with the wrong owner, given that the server may
try to make the directory after it's already dropped to user permissions. It's
normally fine because they throw 777 at it. Not great, but whatever.

- Randolph