Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 465308 - sys-libs/glibc: add USE=suid to control pt_chown suid (and default to off)
Summary: sys-libs/glibc: add USE=suid to control pt_chown suid (and default to off)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL: http://thread.gmane.org/gmane.linux.g...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-09 21:52 UTC by Nikoli
Modified: 2013-04-10 16:40 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikoli 2013-04-09 21:52:29 UTC
Seems now it is possible to stop setting suid for /usr/lib*/misc/glibc/pt_chown, but patching several packages is required.
Comment 1 SpanKY gentoo-dev 2013-04-10 04:49:57 UTC
all relevant info should be in the bug, not external forums, and stackexchange sucks balls.  so here's the gist:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I administer a Gentoo Hardened box that uses file capabilities to eliminate most of the need for setuid-root binaries (e.g. /bin/ping has CAP_NET_RAW, etc).

Infact, the only binary I have left is this one:

abraxas ~ # find / -xdev -type f -perm -u=s
/usr/lib64/misc/glibc/pt_chown
abraxas ~ # 
If I remove the setuid bit, or remount my root filesystem nosuid, sshd and GNU Screen stop working, because they call grantpt(3) on their master pesudoterminals and glibc apparently executes this program to chown and chmod the slave pseudoterminal under /dev/pts/, and GNU Screen cares about when this function fails.

The problem is, the manpage for grantpt(3) explicitly states that under Linux, with the devpts filesystem mounted, no such helper binary is required; the kernel will automatically set the UID & GID of the slave to the real UID & GID of the process that opened /dev/ptmx (by calling getpt(3)).
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Comment 2 SpanKY gentoo-dev 2013-04-10 04:56:16 UTC
i don't think any patching of programs is required.  the glibc code already has logic in grantpt() to say "if the file is already owned be the current user, and the group is already set to 'tty', and the perms are correct, then do nothing".  you can see this in glibc/sysdeps/unix/grantpt.c.

openrc specifically mounts /dev/pts with gid=5 and mode=620 (which is the gid of the tty group, and the perms glibc expects to set up).  that means things should already "just work" if you `chmod -s pt_chown`.  it seems to work for me:
$ grep devpts /proc/mounts 
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
$ sudo chmod -s /usr/lib*/misc/glibc/pt_chown 
$ screen
<works>

if you have a system using glibc and you aren't mounting devpts correctly, well i guess that's your fault.  i'll add USE=suid (which means it'll default to off for glibc) and have it do a sanity check on the mount options of devpts to make sure it is mounted correctly.