Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bad stdout handling #246

Open
guijan opened this issue Mar 19, 2023 · 0 comments
Open

bad stdout handling #246

guijan opened this issue Mar 19, 2023 · 0 comments

Comments

@guijan
Copy link
Contributor

guijan commented Mar 19, 2023

We don't need to know the path of stdout. It doesn't even necessarily have one. The code suffers from the TOCTTOU mentioned in #244, and it also uses /proc (a Linux extension) on non-Linux systems, so it's possible to affect the behavior of scrot by creating a /proc/self/fd/1 file on non-Linux systems.

scrot/src/options.c

Lines 339 to 348 in 99be99f

static const char *getPathOfStdout(void)
{
const char *paths[] = { "/dev/stdout", "/dev/fd/1", "/proc/self/fd/1" };
for (size_t i = 0; i < ARRAY_COUNT(paths); ++i) {
if (accessFileOk(paths[i]))
return paths[i];
}
err(EXIT_FAILURE, "access to stdout failed");
}

This is probably because the imlib APIs we use want an output filename instead of an output file descriptor which is a design bug in imlib because it creates more races and unnecessarily limits the usefulness of the library (can't pick whether or not to overwrite a file, for instance). I looked at the headers of Imlib 1.10.0 and there is no function that writes an image to a given fd.

Imlib has added a function to address this in 1.11.0 on scrot's request, we need to migrate to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants