xwayland: Fix lockfile size confusion

Similarly to Weston (where this code originated), there were two errors
in the X11 lockfile handling.

Firstly, after reading 11 characters from the lock file (which could
have been placed by any process), there was no guarantee of
NUL-termination, meaning strtol could've theoretically run off the end
of the string.

Secondly, whilst writing the new lock, the trailing NUL byte was not
correctly accounted for. The size passed as an input to snprintf takes
the maximum size of the string including the trailing NUL, whilst the
return (and the input to write) gives the actual size of the string
without the trailing NUL.

The code did attempt to check the return value, however snprintf returns
the size of the _potential_ string written, before snprintf culls it, so
this was off by one, and the LF was not being written.

Signed-off-by: Daniel Stone <daniels@collabora.com>

https://bugzilla.gnome.org/show_bug.cgi?id=774613
This commit is contained in:
Daniel Stone 2016-11-17 11:00:25 +00:00 committed by Florian Müllner
parent 925b1aec64
commit f99a086444

View File

@ -224,6 +224,7 @@ try_display (int display,
close (fd);
fd = -1;
pid[10] = '\0';
other = strtol (pid, &end, 0);
if (end != pid + 10)
{
@ -277,7 +278,7 @@ create_lock_file (int display, int *display_out)
char *filename;
int fd;
char pid[11];
char pid[12];
int size;
int number_of_tries = 0;
@ -293,8 +294,10 @@ create_lock_file (int display, int *display_out)
}
/* Subtle detail: we use the pid of the wayland compositor, not the xserver
* in the lock file. */
size = snprintf (pid, 11, "%10d\n", getpid ());
* in the lock file. Another subtlety: snprintf returns the number of bytes
* it _would've_ written without either the NUL or the size clamping, hence
* the disparity in size. */
size = snprintf (pid, 12, "%10d\n", getpid ());
if (size != 11 || write (fd, pid, 11) != 11)
{
unlink (filename);