xserver: do we still need Fopen()

[Enrico Weigelt, metux IT consult]

On 08.02.24 00:19, Alan Coopersmith wrote:

Hi,

>> Does WIN32 still mean 32bit Windows or also more modern ones like
>> w10/w11 ?
>
> I believe it's still defined for 64-bit Windows, as stated on
> https://learn.microsoft.com/en-us/windows/win32/winprog64/additional-considerations
> but I never code or build for Windows, so am not the best person to ask.

Me neither, also didn't have Windows for decades.

Any Windows dev here who can help out ?

>>> If the Xserver is run as setuid root,
>>
>> On which platforms is that still the case ?
>
> Platforms which support users starting the Xserver directly
> (startx/xinit/etc
> instead of via systemd service or display manager) on devices without KMS
> support.

Okay, but which are those, exactly ? Are those still supported at all ?
A comprehensive list of still supported platforms would be great.

> I know Solaris is one, since that's the one I work on,

hmm, and there's no other way around this ?
Does it need the exec'ing code path, or is it fine with temporarily
dropping privs ?

Is being able to start the Xserver as plain user really an important
use case on those platforms ? Or maybe could an tiny suid wrapper (which
filters the args) also be sufficient ?

Are you the Xserver maintainer for Solaris ?

> but I believe
> even some Linux distros still do this - for instance, see the Note about
> the "suid" USE flag on https://wiki.gentoo.org/wiki/Xorg/Guide .

That's strange. Back when I've been using Gentoo last time (must be over
a decade agao), I don't recall running it as suid-root.

>> And does it need to run as root all the time, instead of after opening
>> some devices ?
>
> It needs to run as root when opening the devices (both at startup and
> when VT switching back to the server from another VT).

Does the device need to be re-opened (really another open()) call on VT
switch, or would it be sufficient to do it once early and later drop
privileges ?

> We've got a local mechanism in the Solaris packages that takes a message
> from gdm at login time and setuid's to the user that just logged in,
> since without it, the X server doesn't know what uid to setuid to when
> using a display manager (gdm/xdm/etc.) to login, but that's never gone
> upstream.

Interesting, can you give us more detail ?

Would it be possible to incorparate some special logic for things like
user-passed pathes (and permission checks)

By the way, I've long been wondering whether it would be better to run
the Xserver on entirely separate (possibly temporary) user - or let the
DM start an entirely new server instance (as the logged-in user) after
greeter is done. The second approach could even allow users to customize
server args (eg. whether to allow remote connections).

>> Yes, of course. But can't we just have an extra permission check ?
>
> That would be more code and riskier to implement than the setuid method,
> which just delegates to the kernel to be sure.

Ok, so we should leave the setuid code path (as long as Xserver still
needs to run as setuid-root) and lets focus on the exec'ing code path.

Oh, BTW, just seen that on WIN32, Fopen #define'd to fopen(), thus no
priv dropping at all. So can we assume the other targets
HAS_SAVED_IDS_AND_SETUID ?

According to meson scripts, anything based on
AT&T or SRV4 unix (BSD and as MacOS), as well as Linux do have it.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info at metux.net -- +49-151-27565287