[PATCH weston] launcher: don't exit when user is not root

Christian Stroetmann 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
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035582.html
> 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
> production.
> Thanks,
> pq

Hello everybody

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 
everybody eventually.

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.

Best Regards
Christian Stroetmann

More information about the wayland-devel mailing list