weston-launch: Provide a default version that doesn't require PAM

Please, explain how starting weston as root is supposed to be a valid use case.

Please, also explain why you need weston-launch for running Weston as root.

Third, weston-launch is going to be removed: #488 (closed)

I'm only the submitter, not the author, and if this is not acceptable, that's ok to me. I'll ping the people involved over email, so pls don't close yet.

Sure, that's fine. It's just that "get rid of PAM" seems to be a recurring theme, and it has never been properly justified which is why all those proposals have been closed before.

If there is a good justification, then fine, but so far I'm not aware of any.

Yocto ships the patch because they also ship with an option to disable PAM, on the grounds that it's unnecessary if you have very static user management.

Sure, but then you don't need weston-launch to begin with, so just disable the whole program instead.

Yep.

As @daniels said, we allow distros without PAM support. We currently use weston-launch because we support sysvinit as an alternative in minimal systems or license-sensitive environments.

Why do you still need weston-launch with sysvinit when you do not have PAM? Why do you not disable building weston-launch completely in that case?

You could as well just run weston directly as far as I can imagine, there should not be any need for weston-launch. This is what puzzles me. Is it just cargo-cult to use weston-launch, or is there an actual reason?

You don't need logind or any logind replacement daemon either to run weston directly as root or as any statically configured user.

@pq, it has been a while since the last time I played with it, so I don't recall the details. However, if you say it'd work, I trust you. It'd be great if there is a doc describing it, though.

That's the problem: I am not absolutely sure it will work, because I probably cannot imagine what you are doing. So I want to learn exactly what you are doing and how it doesn't work, not commit a "blind fix". Maybe you can do your thing in a better way, or maybe we do need to fix something upstream.

I recall a long time ago having a look at some Yocto related Weston integration and being so horrified of all the cruft there that I just walked away. Hence I prefer the people actually working on that stuff to tell me what goes wrong if they do things the way I imagine it should work.

Nowadays we do have some docs in https://wayland.pages.freedesktop.org/weston/toc/running-weston.html but I don't know if they cover your use case. You can find those docs via the Wayland main site: https://wayland.freedesktop.org/ → Software → Weston documentation.

The mainline Yocto stuff is pretty sane to be fair; it's the vendors who fork it who massacre it. The least-sane thing in mainline Yocto is supporting no-PAM and musl, which are niche but not ridiculous.

FWIW, I do not have any strong feelings for this patch; if its authors do not speak up, I will simply drop it from yocto, and adjust configurations and tests so the yocto CI doesn't fail. We try to enforce 'upstream first' policy for invasive changes like this, but sometimes they slip through.

Ok, great! I would like to hear how that works out. To clarify, instead of adding "disable PAM" you would just use "do not build weston-launch" in the Weston build configuration. The net effect should be the same, with the exception that weston-launch won't be available, but one should be able to replace that with weston and maybe little scripting around it.

I wouldn't call this invasive but more a matter of policy. We try to keep the number of different supported ways to run Weston small upstream to make it more manageable and to promote best practices.

Currently I think we have these options:

with logind, for full-fledged multi-user OS
with seatd, for multi-user OS without logind
as root without any daemon, for developer testing and maybe for systems without users

I guess "without any daemon but as a non-root user" could be another case, but it feels like a half-way house that does nothing well: you are playing around with separate users, but you still need to allow that user access to input devices which means you may be vulnerable to input spying.

Sounds like people are happy to try things without weston-launch, so I will close this MR for now. If you get new information about needing this patch, please do not hesitate to re-open and comment here. Thanks!

Also remember that weston-launch is going to be removed completely from upstream, probably after the next release cycle. I would recommend looking into libseat particularly if you are not using systemd-logind.

I've sent RFC patches for weston 10.0.0 in yocto, pls take a look:

https://lists.openembedded.org/g/openembedded-core/message/161155

https://lists.openembedded.org/g/openembedded-core/message/161156

Upstream has deprecated both weston-launch and fbdev backend, so let's
not delay the inevitable and find replacements.

Fbdev can be replaced by passing --use-pixman to drm backend;
this will bypass the opengl paths and use CPU for rendering.
Apply where GL is too slow or unavailable.

weston-launch can be replaced by starting weston directly, with
a seat management daemon for support. This is provided either
by systemd, or on systemd-less systems, by seatd. The sysvinit
startup scripts and tests have been rewritten accordingly. Bonus
fix: under sysvinit weston now starts under weston user as it should,
and not under root.

Looks good, thankyou!

closed

Admin message

Admin message

weston-launch: Provide a default version that doesn't require PAM

Merge request reports

Activity