Bug 24844 - /usr/libexec/pt_chown has wrong permissions
/usr/libexec/pt_chown has wrong permissions
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
i386 Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-24 08:24 EST by Need Real Name
Modified: 2016-11-24 10:05 EST (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-01-24 08:24:45 EST
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()
does.
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 09:55:15 EST
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
permissions.
mc spawns a subshell when I login as normal user on console without any problems.
Comment 2 Need Real Name 2001-01-25 01:24:32 EST
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 01:35:37 EST
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.