fixes issue #484 (race condition with message to/from weston launch)
The race condition occurs after weston sends the WESTON_LAUNCHER_OPEN
message to weston-launch. The race is between when weston-launch replies
with the fd handle versus weston-launch sending an activation message. If
weston-launch sends an activation message before sending the fd handle,
then weston will be in an invalid state.
To fix this, I modified the fd handle reply that weston-launch sends to
include a message id at the beginning, which I called
WESTON_LAUNCHER_OPEN_REPLY. Along with this, weston now inspects the
first part of any reply to determine whether it is an activation message
or a reply to the OPEN message. In the newly handled case that it's an
activation message, it tracks whether the latest result is a deactivate
message and stores it in a flag to be handled once the open function has
completed.
Signed-off-by: Jonathan Marler <johnnymarler@gmail.com>
When using weston-launch launcher deactivating the VT is sometimes
racy and leads to Weston still being displayed. The launcher-direct.c
backend makes sure that the session signal is emitted first, then DRM
master is dropped and finally the VT switch is acknowledged via
VT_RELDISP.
However, in the weston-launch case the session signal is emitted via
a socket message to the weston process, which might get handled a bit
later. This leads to dropping DRM master and acknowledging the VT
switch prematurely.
Add a socket message which allows weston to notify weston-launch that
the signal has been emitted and deactivating can be proceeded.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
On weston-launch exit we see errors such as:
failed to restore keyboard mode: Invalid argument
failed to set KD_TEXT mode on tty: Invalid argument
This has been resolved by making sure the tty file descriptor
does not get closed. However, the ioctrl's KDSKBMODE/KDSETMODE
and VT_SETMODE still fail with -EIO:
failed to restore keyboard mode: Input/output error
failed to set KD_TEXT mode on tty: Input/output error
It turns out the reason for this lies in some very particular
behavior of the kernel, the separation of weston-launch/weston
and the fact that we restore the tty only after the weston
process quits: When the controlling process for a TTY exits,
all open file descriptors for that TTY are put in a hung-up
state! For more details see this systemd-logind issue:
https://github.com/systemd/systemd/issues/989
We can work around by reopening the particular TTY. This allows
to properly restore the TTY settings such that a successive VT
switch will show text terminals fine again.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since weston-launch is a setuid-root program we should be extra careful:
Check for a potential string trunction. Move the check in a separate
function and return with error in case trunction has happened.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Currently weston-launch does not activate the VT when opening the
terminal directly (e.g. using --tty=/dev/tty7). Weston takes full
control over the terminal by switching it to graphical mode etc.
However, the old VT stays active as can be seen when looking at
sysfs:
# cat /sys/class/tty/tty0/active
tty1
Always switch to the new VT to make sure the correct VT is active.
This aligns with how TTY setup is implemented in launcher-direct.c.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add newline character at the end of the error message to make sure we
get a new line after this error has been printed.
Fixes: a1450a8a71 ("make error() portable")
Signed-off-by: Stefan Agner <stefan@agner.ch>
In case an user is given but no tty, the code opens tty0 to allocate a
new tty. With that ttynr is known.
In case a tty name is given the user must be given too. In this case
we later recover the ttynr by using stat on the file tty file descriptor
which allows as to find the ttynr by looking at the devices minor number.
However, the third case, when no user and no tty name is given, we do
not get the ttynr.
This hasn't been a problem in practise since ttynr has not been used.
However, it makes sense to get the ttynr always for consistency. Also
upcomming fixes will start to make use of ttynr.
Fixes: 636156d5f6 ("weston-launch: Don't start new session unless -u is given")
Signed-off-by: Stefan Agner <stefan@agner.ch>
The tty file descriptor is used in signal handling (when switching
VT via SIGUSR1/SIGUSR2 for the VT_RELDISP ioctrl) and in quit() when
weston-launch exits for the KDSKBMUTE/KDSKBMODE/KDSETMODE/VT_SETMODE
ioctrls.
This fixes VT switching when using weston-launch from a non-VT shell
(e.g. ssh or from within a container).
Signed-off-by: Stefan Agner <stefan@agner.ch>
Use exec to make sure the direct child process of weston-launch is
weston. This makes sure that signal delivery (SIGINT/SIGTERM) is
properly forwarded to weston.
Fixes ff3230952a ("weston-launch: Run weston in the user login shell")
Signed-off-by: Stefan Agner <stefan@agner.ch>
The printf() format specifier "%m" is a glibc extension to print
the string returned by strerror(errno). While supported by other
libraries (e.g. uClibc and musl), it is not widely portable.
In Weston code the format string is often passed to a logging
function that calls other syscalls before the conversion of "%m"
takes place. If one of such syscall modifies the value in errno,
the conversion of "%m" will incorrectly report the error string
corresponding to the new value of errno.
Remove all the occurrences of the specifier "%m" in Weston code
by using directly the string returned by strerror(errno).
While there, fix some minor indentation issue.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
error() is not posix but gnu extension so may not be available on all
kind of systemsi e.g. musl.
Signed-off-by: Randy 'ayaka' Li <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
If the user is in group 0, we'd exit the loop early with a failure. Make sure
we run through all groups.
https://gitlab.freedesktop.org/wayland/weston/issues/86
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[Pekka: fix one whitespace]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Explain that -u requires root and -t requires -u. Most importantly,
document in what format does -t expect the tty to be given.
It has been confusing, because Weston's --tty option takes an integer,
weston-launch takes a full device path.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Fix an issue introduced in:
commit ab4999492c
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Fri Jul 19 21:26:24 2013 -0700
weston-launch: Drop sleep_fork option
where the option string accidentally became "t::". That causes
$ weston-lauch -t /dev/tty4
to be parsed incorrectly, as if -t option had no argument and the tty
path gets passed to weston which errors out because of it.
This patch fixes the above to work as expected.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
setup_tty() function uses the tty argument for choosing the tty/VT only
if wl->new_user (the -u option) is given. If the tty option is given
without -u, it will only be used for misleading error messages.
To make it clear to the user that -t without -u does not work the way
one might think, let weston-launch exit with an error in that case.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
HAVE_LIBDRM was used as a condition for the launcher infrastructure to
call libdrm.so functions. It was set by an independent test for libdrm,
which would silently continue if libdrm was not found. It was assumed
that if you enabled a feature that used libdrm at runtime, the test for
that feature would imply that HAVE_LIBDRM is also set. This was quite
subtle.
The only feature that actually uses libdrm.so at runtime is the DRM
backend. No other backend needs the libdrm calls in the launcher
infrastructure.
Therefore to simplify things, stop using HAVE_LIBDRM and use
BUILD_DRM_COMPOSITOR instead. If you enable the DRM compositor, you
automatically also get libdrm support in the launchers.
There are still things depending on LIBDRM_CFLAGS and LIBDRM_LIBS, so
the test cannot be removed completely.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This way, the environment is correctly preserved for weston. Since
commit 636156d5f6, clearenv() is only
called when we open a new PAM session, so it makes sense to only use a
login shell in that case.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This clarifies what is supposed to be the libweston code.
v2: screen-share.c is already in compositor/ instead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
Exit the program if an unrecognized command line option is found.
Signed-off-by; Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Tested-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
According to POSIX standard "upon successful completion, putenv() shall
return 0; otherwise, it shall return a non-zero value." Unlike in
setenv() we should not be checking only for negative values.
Signed-off-by: Dawid Gajownik <gajownik@gmail.com>
error(1, ...) already will exit, per man page: "If status has a nonzero
value, then error() calls exit(3) to terminate the program using the
given value as the exit status." So exit(EXIT_FAILURE) is never
reached.
The EXIT_FAILURE macro is guaranteed to be non-zero. Typically it's
just 1, but on some systems (e.g. OpenVMS apparently) exit(1) means
success so EXIT_FAILURE there is defined to some other non-zero value.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
For functions that test if something is true/valid and return a 1
or 0, it makes sense to switch to bool.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If libdrm is available, weston-launch and launcer-util.c will support
getting the drm device and setting and dropping drm master, otherwise
we'll only support getting input devices.
On shutdown, we can risk having a pending vt switch that we normally
handle in the vt signal handler. However as we put the vt back in VT_AUTO
mode, the pending VT switch will go through and if we haven't dropped
drm master at that point, we could switch to another display server
without dropping drm master. That will typically crash the other server,
so let's try to make sure we don't do that.
https://bugs.freedesktop.org/show_bug.cgi?id=70877
We used to leak the input fds, as weston would reopen all fds on vt
enter. We could just close them after sending the open fd through the
socket, but this patch also adds support for the new EVIOCREVOKE evdev
ioctl, that revokes the fd in question (including the copy that we
sent to the compositor).
https://bugs.freedesktop.org/show_bug.cgi?id=70849
weston-launch has two supported use cases now: either launch from
and VT login as a regular user (running within that session) or
from an init script (systemd or such) with the -u option to create
a session for the specified user. Running from within X or ssh is
not possible. It's still possible to run weston as root from X or ssh
but that's strictly a development/debug/test feature.
https://bugs.freedesktop.org/show_bug.cgi?id=69727
The struct weston_launcher object will now either handle tty and vt switching
details in-process (when running weston directly as root) or talk to
the weston-launch process.
The current code works if pw->pw_shell is bash because:
"If the shell is started with the effective user (group) id not equal to
the real user (group) id, and the -p option is not supplied, these actions
are taken and the effective user id is set to the real user id."
Thus, for bash, weston's EUID == UID.
For zsh, the -p option "is enabled automatically on startup if the effective
user (group) ID is not equal to the real user (group) ID."
Thus, weston's EUID = 0, and if pw_shell is zsh, /run/user/$UID/wayland-0 is
created with euid root and not writeable by the user, causing all clients to
fail.
Fix this by always dropping privileges to the user.
Regression introduced in 636156d.
Jonathan Marler
Stefan Agner
Antonio Borneo
Marius Vlad
Randy Li
Peter Hutterer
Sergei Trofimovich
Pekka Paalanen
Daniel Stone
Quentin Glidic
Tom Hochstein
Dawid Gajownik
Bryce Harrington
Murray Calavera
Derek Foreman
Kristian Høgsberg
Tomeu Vizoso
Rob Bradford
Eduardo Lima