1 |
tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things will |
2 |
happen and it's (probably) all your fault |
3 |
|
4 |
when you run grantpt(), glibc attempts to set up your pty with correct |
5 |
ownership & permissions. it does so by executing a setuid helper called |
6 |
pt_chown as needed. we all know setuid==bad, so let's do something about it. |
7 |
|
8 |
this system is a throw back to the bad old bsd pty days where you had a ton of |
9 |
pre-allocated nodes in /dev/ named pty??. since the user has requested a new |
10 |
pty, the system had to make sure it had correct permissions before giving it |
11 |
back (it might be the default of root:root, or it might have the previous |
12 |
user's settings which would be super bad). this system sucks for many |
13 |
reasons. |
14 |
|
15 |
with Linux, we have devpts mounted at /dev/pts/ which provides dynamic UNIX 98 |
16 |
ptys via the /dev/ptmx control node. the kernel knows that when you request a |
17 |
new pty, the sane thing is to set the default uid/gid to your own process's |
18 |
uid/gid. it even goes further and allows you to specify (at mount time) |
19 |
default gid/permissions. |
20 |
|
21 |
with openrc (and in baselayout-1.12, but i'm pretty sure it's been this way |
22 |
for even longer), our default mount uses gid=5 (the tty group) and mode=620 |
23 |
(what we want). that means when a new pty is requested, the kernel |
24 |
automatically sets the ownership of the new file to the process's uid and the |
25 |
mounted group setting (tty), as well as setting the perms to 620. |
26 |
|
27 |
back to glibc, when you call grantpt(), it checks the current uid/gid/mode. |
28 |
if they all match what it expects (and it should with our default devpts mount |
29 |
opts), it returns w/out doing any real work (like calling the setuid pt_chown |
30 |
helper). that means this binary is sitting around with setuid perms for no |
31 |
good reason. |
32 |
|
33 |
i plan on updating the latest glibc to add USE=suid. in pkg_preinst and |
34 |
ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if |
35 |
it doesn't find one, i'll have it call `die`. if the bsd pty scenario wasn't |
36 |
long dead, and the devpts option didn't have gid=/mode= options, then it might |
37 |
be reasonable to have it warn and do `chmod +s`. but i can't think of any |
38 |
legitimate reasons for not using devpts & mounting it correctly. this is the |
39 |
right answer even in the embedded world. |
40 |
-mike |