diff mbox series

sysvinit: create tmpfile dir for x11 domain socket

Message ID 20251007234809.435300-2-rs@ti.com
State New
Headers show
Series sysvinit: create tmpfile dir for x11 domain socket | expand

Commit Message

Randolph Sapp Oct. 7, 2025, 11:48 p.m. UTC
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.

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.

Signed-off-by: Randolph Sapp <rs@ti.com>
---
 meta/recipes-core/sysvinit/sysvinit/02_x11  | 6 ++++++
 meta/recipes-core/sysvinit/sysvinit_3.14.bb | 2 ++
 2 files changed, 8 insertions(+)
 create mode 100644 meta/recipes-core/sysvinit/sysvinit/02_x11

Comments

Ross Burton Oct. 15, 2025, 2:37 p.m. UTC | #1
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.

> 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
Randolph Sapp Oct. 15, 2025, 5:22 p.m. UTC | #2
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.

>> 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
Randolph Sapp Oct. 18, 2025, 12:01 a.m. UTC | #3
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
Randolph Sapp Oct. 20, 2025, 9:30 p.m. UTC | #4
On Fri Oct 17, 2025 at 7:01 PM CDT, Randolph Sapp via lists.openembedded.org wrote:
> 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

Are we still dead set on splitting this into both xwayland and xorg-xserver and
conditionally masking it based on whether or not systemd is selected? Feels odd.
diff mbox series

Patch

diff --git a/meta/recipes-core/sysvinit/sysvinit/02_x11 b/meta/recipes-core/sysvinit/sysvinit/02_x11
new file mode 100644
index 0000000000..35c3698479
--- /dev/null
+++ b/meta/recipes-core/sysvinit/sysvinit/02_x11
@@ -0,0 +1,6 @@ 
+# Volatile entries to match systemd
+# https://github.com/systemd/systemd/blob/main/tmpfiles.d/x11.conf
+d root root 1777 /tmp/.X11-unix none
+d root root 1777 /tmp/.ICE-unix none
+d root root 1777 /tmp/.XIM-unix none
+d root root 1777 /tmp/.font-unix none
diff --git a/meta/recipes-core/sysvinit/sysvinit_3.14.bb b/meta/recipes-core/sysvinit/sysvinit_3.14.bb
index d4bb797624..368d77cc2e 100644
--- a/meta/recipes-core/sysvinit/sysvinit_3.14.bb
+++ b/meta/recipes-core/sysvinit/sysvinit_3.14.bb
@@ -17,6 +17,7 @@  SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
            file://rcS \
            file://bootlogd.init \
            file://01_bootlogd \
+           file://02_x11 \
            "
 SRC_URI[sha256sum] = "c90874b8c054a35991fb8c4d30c443ed1e9b1815ff6165c7b483f558be4e4b53"
 
@@ -104,6 +105,7 @@  do_install () {
 
 	install -d ${D}${sysconfdir}/default/volatiles
 	install -m 0644 ${UNPACKDIR}/01_bootlogd ${D}${sysconfdir}/default/volatiles
+	install -m 0644 ${UNPACKDIR}/02_x11 ${D}${sysconfdir}/default/volatiles
 
 	chown root:shutdown ${D}${base_sbindir}/halt ${D}${base_sbindir}/shutdown
 	chmod o-x,u+s ${D}${base_sbindir}/halt ${D}${base_sbindir}/shutdown