On 2015-12-04 17:20, Jakub Wilk wrote:
> Hi Aurelien!
>
> Thanks for looking into this bug.
>
> * Aurelien Jarno <aurel...@aurel32.net>, 2015-12-04, 15:05:
> >>Couldn't libc just leave ownership/permission as they are if /dev/pts is
> >>a devpts filesystem?
> >
> >What do you mean? The libc doesn't change anymore the permissions
> >(pt_chown has been removed for security reasons), and that's actually the
> >issue.
>
> grantpt() calls chown() or chmod() if the device ownership or mode is not
> what it expects. See sysdeps/unix/grantpt.c, lines 130-171.
>
> And it Domenico's strace output, it was chown() that failed:
>
> chown("/dev/pts/2", 1000, 5) = -1 EPERM (Operation not permitted)
>
> Now, I realize that changing ownership and permissions of the device is
> exactly what grantpt() is documented to do. The problem is that it turns a
> minor configuration problem (devpts mounted without gid=5) into a big
> usability problem, which is difficult to debug.
>
> IMO it'd be practical for glibc to assume that the devpts filesystem is
> always correctly configured and that changing ownership and permissions is
> not necessary. This would also fix bug #705056.
It might be practical and might work when grantpt() is preceded by the
call to posix_openpt(). It might break some programs which do other
things in between and which really assume that grantpt() is going to do
what it is supposed to do. It might even have some security implications.
And it will also likely be a POSIX violation as it clearly precise the
mode and the group to be used.
> >>* Domenico Andreoli <domenico.andreoli...@gmail.com>, 2015-12-02, 17:13:
> >>>$ grep devpts /etc/fstab
> >>>none /mnt/sid64/dev/pts devpts defaults
> >>>0 0
> >>>none /mnt/sid64/home/chernobyl/dev/pts devpts defaults
> >>>0 0
> >>
> >>"defaults" are not correct options. You need "gid=5" at least.
> >
> >Well they are the one in the chroots...
> >
> >>All devpts fstab entries need to have correct options, because all
> >>devpts filesystems are shared by default. (You can probably use the
> >>"newinstance" option to disable sharing them.)
> >
> >You really mean the other entries in the fstab are causing the permissions
> >of /dev/pts to be changed?
>
> It's very surprising, but yet, this is the case, at least on Linux:
>
> # mount | grep /dev/pts
> devpts on /dev/pts type devpts
> (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
> # mount -t devpts devpts /mnt
> # mount | grep devpts
> devpts on /dev/pts type devpts
> (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
> devpts on /mnt type devpts (rw,relatime,mode=600,ptmxmode=000)
>
> As you can see, options changed for both mounts.
That's totally stupid and it seems to be also the case for chroots. And
it seems that at least cowbuilder is mounting /dev/pts in the chroot
with the default options.
> >In that case given the issue is due to a user misconfiguration, I guess we
> >should just try to detect it, display a note and fail the installation.
>
> Warning the user would be certainly a good idea. But of course that would
> only help if the devpts filesystem was misconfigured at installation time.
> For me, this wasn't the case.
What was the issue on your case?
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
