This issue affects Screen 5.0.0 when it runs with setuid-root privileges. The
function `logfile_reopen()` [3] does not drop privileges
while operating on a user supplied path. This allows unprivileged users to
create files in arbitrary locations with `root` ownership, the invoking user's
(real) group ownership and file mode 0644. All data written to the Screen PTY
will be logged into this file.  Also already existing files can be abused for
logging in this manner: the data will be appended to the file in question, but
the file mode and ownership will be left unchanged.

Screen correctly drops privileges when it initially opens the logfile. The
privilege escalation becomes possible as soon as Screen believes it is
necessary to reopen the logfile. Screen checks this by calling
`stolen_logfile()` [4] before writing to the file. The call
to `logfile_reopen()` happens when the link count of the originally opened
logfile drops to zero, or if it unexpectedly changes in size. This condition
can be triggered at will on the end of the unprivileged user.