[PATCH weston] launcher: don't exit when user is not root
stroetmann at ontolab.com
Wed Nov 1 04:00:08 UTC 2017
On the 30th of October 2017 16:02, Pekka Paalanen wrote:
> On Mon, 30 Oct 2017 15:20:42 +0100
> Emre Ucan<eucan at de.adit-jv.com> wrote:
>> weston does not need to be root.
>> It requires adjusting ownership on the given tty device.
>> If weston does not have proper rights, it will get
>> an error at startup anyway.
>> Signed-off-by: Emre Ucan<eucan at de.adit-jv.com>
>> libweston/launcher-direct.c | 3 ---
>> 1 file changed, 3 deletions(-)
>> diff --git a/libweston/launcher-direct.c b/libweston/launcher-direct.c
>> index a5d3ee5..b05d214 100644
>> --- a/libweston/launcher-direct.c
>> +++ b/libweston/launcher-direct.c
>> @@ -276,9 +276,6 @@ launcher_direct_connect(struct weston_launcher **out, struct weston_compositor *
>> struct launcher_direct *launcher;
>> - if (geteuid() != 0)
>> - return -EINVAL;
>> launcher = zalloc(sizeof(*launcher));
>> if (launcher == NULL)
>> return -ENOMEM;
> NAK, for the reasons explained in
> To summarize, it's not only tty permissions but DRM and input devices
> as well. If you set all these so that weston can actually run without
> root using the direct launcher, then quite likely you have opened some
> security holes.
> The direct launcher is specifically meant for running weston as root.
> Running as root is only for debugging and development, never for
Personally, I do prefer the way Pekka handles the matter and applying a
little more advanced software engineering is not a bad choice.
But sadly to say and without any offence, for sure, reality and life is
very different and diversified when compared with our desires.
Indeed, there are pros and cons for both sides:
In general, Weston must be as flexible as possible for being accepted by
Furthermore, an embedded system has always been and still is a special
case where everything goes, so to say. In this respect, it is very hard
or even impossible to convince a developer of an embedded system to
carry the unnneeded code along, specifically in the case that somebody
does not need any safety, security, and reliability properties, or/and
exactly knows what she/he is doing and hence is willing to take any
risks, as said by the embedded system developers in this thread.
Therefore, using Weston in a root debug or special embedded system way
should not be excluded as somekind of a common option.
This leads to various potential compromises, such as for example:
(a) a custom-made configuration of a development tool (e.g. CASE tool)
excludes the unneeded part of the safe, secure, and reliable Weston code
for an individual architecture, framework, or project,
(b) a compiler flag and a related message that shows a clear warning
that the result of the compilation is not included in the safe, secure,
and reliable Weston environment anymore, or
(c) an own subproject of Weston with an own chapter in the documentation
for the root debug development option and the special embedded system
"use case", that
- could be titled "Weston Root Debug (Weston RD)" or "Weston Bare Metal
(Weston BM)" for example, and
- explains the differences between the proper Weston and the special
Weston variants and also gives a clear warning about the potential
safety, security, and reliability issues.
More information about the wayland-devel