Bug 24844 - /usr/libexec/pt_chown has wrong permissions
Summary: /usr/libexec/pt_chown has wrong permissions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-24 13:24 UTC by Need Real Name
Modified: 2016-11-24 15:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-25 06:24:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-01-24 13:24:45 UTC
Symptoms: run mc under non-privileged user account and you are unable to
use subshell there.

Reason: after glibc-common-2.2-12 (or glibc before splittting it to two
rpms) install, the file permissions for /usr/libexec/pt_chown are set
incorrectly. They are 600, while they must be 755, and pt_chown must be
suid root also.

Consequences: glibc always fails in grantpt() returning ENOEXEC in errno,
because of the incorrect file permisions in pt_chown

Why? Because /usr/libexec/pt_chown is a helper app used by glibc to change
ownership of the slave end of a pseudo-terminal. This is what grantpt()
Since permissions are set to 600 on pt_chown, glibc can't execute it from
the grantpt() function, and hence we get ENOEXEC.

Comment 1 Jakub Jelinek 2001-01-24 14:55:15 UTC
This is intentional. We don't want to ship an unneeded suid program
(it is not needed when you have /dev/pts mounted) but we ship it there so
folks who explicitely don't want to use /dev/pts (installer sets up /dev/pts
mounting btw) can chmod 4755 /usr/libexec/pt_chown themselves.
/usr/libexec/pt_chown had 600 permissions for long time already, I've just
checked glibc-2.1.92-14 which shipped in 7.0 originally and it has the same
mc spawns a subshell when I login as normal user on console without any problems.

Comment 2 Need Real Name 2001-01-25 06:24:32 UTC
How about adding post-install script to glibc-common, which detects absence of
/dev/pts and sets proper permissions to pt_chown?

Your mc works fine either because you have /dev/pts or because permissions on
pt_chown are 755/suid. In my case I did not have /dev/pts and glibc-common did
not detect it during install and mc wouldn't spawn subshell. Because without
/dev/pts glibc needs pt_chown with access rights 755, but again, glibc-common
doesn't do that, EVEN when there is no /dev/pts.

So this is rather a bug anyway. glibc-common must detect whether there is
/dev/pts and act accordingly, adjusting permissions for /usr/libexec/pt_chown.

Comment 3 Need Real Name 2001-01-25 06:35:37 UTC
NOTE: I didn't notice /dev/pts in my mount output:

[pirks@alg158ghy74l ~]$ mount
/dev/hda8 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hda7 on /mnt/fat type vfat (rw,uid=500,gid=500)
/dev/hda3 on /mnt/fat2 type vfat (rw,uid=500,gid=500)
/dev/hda5 on /mnt/ext2 type ext2 (rw)
[pirks@alg158ghy74l ~]$ ls /dev/pts
ls: /dev/pts: No such file or directory

So now the question is why installer did not set up /dev/pts on my system, which
is another issue.
Is there a way I can check if /dev/pts was installed by glibc-common? A special
file somewhere or something like? OK, I can check the post-install script in a
while. If I find something interesting, I'll post it here.

Note You need to log in before you can comment on or make changes to this bug.