Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Wed, 17 Apr 2013 14:35:27 -0400
Mike Frysinger wrote:
> On Saturday 13 April 2013 13:06:04 Jeroen Roovers wrote:
> > On Fri, 12 Apr 2013 16:08:10 -0400 Mike Frysinger wrote:
> > > that you remember. i think it's more likely you copy & pasted some
> > > line a long time ago than baselayout modified it for you.
> >
> > Exactly, but where did that come from?
>
> probably worthwhile to track down to better understand, but i don't think the
> answer will change the result
>
> > > two people who have installs that are a decade old doesn't incline me
> > > to write a news entry. not when the ebuild itself contains a sanity
> > > check that triggers exactly as needed and includes an error message
> > > explaining things. we aren't talking about an upgrade here that will
> > > silently & accidentally break your box on next boot (like udev &
> > > friends), or will break running programs (like SONAME bumps, although
> > > that's a much less of a problem now that portage handles things
> > > automatically).
> >
> > I have been looking through old copies of the Handbook in the last
> > hour, assuming the fstab entry may have been included there at some
> > point. I haven't done anything like a thorough search, but I assume it
> > may have slipped into the handbook at some point and was later removed
> > (as some CVS log entries from 2004 seem to suggest).
>
> it's at times like this i wish we had a git repo. `git log -p -C -M` is
> great
> at tracking this sort of stuff down.
> -mike
I usually rsync locally cvs tree and then convert it to git:
rsync://anonvcs.gentoo.org/vcs-public-cvsroot/{CVSROOT,gentoo/xml/}
cvsps --root :local:/path/to/ --fast-export gentoo/xml/htdocs | git
fast-import
Takes around 5 minutes to convert.
$ git log --stat -S ' devpts ' # shows that 'devpts' suggestion comes from an
LVM guide:
commit 658b3ab06b4919f102efaffe756b8b6c1d378fd0
Author: drobbins
Date: Sat Nov 9 18:47:44 2002 +
try #10030
doc/cz/altinstall.xml | 360
+++
doc/en/altinstall.xml | 350
2 files changed, 710 insertions(+)
and it is still there.
$ git grep devpts:
doc/ca/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/da/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/de/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/en/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/en/articles/lvm-p2.xml:none/dev/pts devpts
mode=620 0 0
doc/es/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/es/articles/lvm-p2.xml:none/dev/pts devpts
mode=620 0 0
doc/fr/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/fr/selinux-uml-guide.xml:none/dev/ptsdevpts gid=5,mode=620
00
doc/id/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/it/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/it/articles/lvm-p2.xml:none/dev/pts devpts
mode=620 0 0
doc/ja/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/nl/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/pl/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/pt_br/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/ru/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/vi/altinstall.xml:none on /dev/pts type devpts (rw,gid=5,mode=620)
doc/zh_cn/articles/lvm-p2.xml:none/dev/pts devpts
mode=620 0 0
Looks like many are incorrect including this:
http://www.gentoo.org/doc/en/articles/lvm-p2.xml
HTH
--
Sergei
signature.asc
Description: PGP signature
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Wed, Apr 17, 2013 at 2:35 PM, Mike Frysinger wrote: > it's at times like this i wish we had a git repo. `git log -p -C -M` is great > at tracking this sort of stuff down. I don't want to hijack this thread, but I don't believe we have a tracker for the migration of docs / website / etc to git. Is there simply not interest? I'm not sure what complexities exist compared to the portage migration. Rich
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Saturday 13 April 2013 13:06:04 Jeroen Roovers wrote: > On Fri, 12 Apr 2013 16:08:10 -0400 Mike Frysinger wrote: > > that you remember. i think it's more likely you copy & pasted some > > line a long time ago than baselayout modified it for you. > > Exactly, but where did that come from? probably worthwhile to track down to better understand, but i don't think the answer will change the result > > two people who have installs that are a decade old doesn't incline me > > to write a news entry. not when the ebuild itself contains a sanity > > check that triggers exactly as needed and includes an error message > > explaining things. we aren't talking about an upgrade here that will > > silently & accidentally break your box on next boot (like udev & > > friends), or will break running programs (like SONAME bumps, although > > that's a much less of a problem now that portage handles things > > automatically). > > I have been looking through old copies of the Handbook in the last > hour, assuming the fstab entry may have been included there at some > point. I haven't done anything like a thorough search, but I assume it > may have slipped into the handbook at some point and was later removed > (as some CVS log entries from 2004 seem to suggest). it's at times like this i wish we had a git repo. `git log -p -C -M` is great at tracking this sort of stuff down. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
> "JR" == Jeroen Roovers writes: JR> On Fri, 12 Apr 2013 16:08:10 -0400 JR> Mike Frysinger wrote: >> that you remember. i think it's more likely you copy & pasted some >> line a long time ago than baselayout modified it for you. JR> Exactly, but where did that come from? If it didn't come from baselayout or openrc, the most likely scenario is some gui crud. I probably looked through the list of apps once I got a menu tree based on .desktop files added to my wm. And with sudo(8) configured for convenience, if I ran an app which edits fstab(5), it would not have needed to ask for my sudo passwd to work. And gnome seems to prefer fully to rewrite files in their own quirky style. Rather than just making changes. (Rewrites like that are why I tend to chattr+i a lot of files in /etc.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Fri, 12 Apr 2013 16:08:10 -0400 Mike Frysinger wrote: > that you remember. i think it's more likely you copy & pasted some > line a long time ago than baselayout modified it for you. Exactly, but where did that come from? > two people who have installs that are a decade old doesn't incline me > to write a news entry. not when the ebuild itself contains a sanity > check that triggers exactly as needed and includes an error message > explaining things. we aren't talking about an upgrade here that will > silently & accidentally break your box on next boot (like udev & > friends), or will break running programs (like SONAME bumps, although > that's a much less of a problem now that portage handles things > automatically). -mike I have been looking through old copies of the Handbook in the last hour, assuming the fstab entry may have been included there at some point. I haven't done anything like a thorough search, but I assume it may have slipped into the handbook at some point and was later removed (as some CVS log entries from 2004 seem to suggest). jer
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Friday 12 April 2013 15:41:55 James Cloos wrote: > > "MF" == Mike Frysinger writes: > >> It will impact everyone who has /dev/pts in fstab(5). > > MF> don't do that. > > *I* didn't. that you remember. i think it's more likely you copy & pasted some line a long time ago than baselayout modified it for you. two people who have installs that are a decade old doesn't incline me to write a news entry. not when the ebuild itself contains a sanity check that triggers exactly as needed and includes an error message explaining things. we aren't talking about an upgrade here that will silently & accidentally break your box on next boot (like udev & friends), or will break running programs (like SONAME bumps, although that's a much less of a problem now that portage handles things automatically). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Friday 12 April 2013 13:20:11 Maxim Kammerer wrote: > On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger wrote: > > i don't know what you mean. if the ebuild detects devpts being mounted > > and the mount is incorrect, it will die. if you don't have devpts > > mounted at all, then it assumes you know what you're doing. > > What I am saying is that you make no distinction between build > environment and deployment environment. Quite a few users build their > Gentoo systems in a chroot. In that case, whole /dev, or its portions > (including /dev/pts) can be bind-mounts from the host filesystem, and > /dev/pts does not need to have the correct permissions. However, you > *would* see such a bind-mount as a devpts mount in /proc/mounts. So > why not print a warning — what's the point of dying in pkg_preinst? unless you have a good reason for having the host devpts being mounted wrong, i'm not inclined to support this. every major distro that matters that i know of does it this way and has for a long time: Debian, Ubuntu, Fedora, Gentoo. if it encourages people to fix their host distro to also not suck, well that's just a bonus. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
> "MF" == Mike Frysinger writes: >> It will impact everyone who has /dev/pts in fstab(5). MF> don't do that. *I* didn't. I don't know /what/ added it, but something did. With noauto, just like the other reported case. It shouldn't matter how rare it is though. A general announcement won't hurt anyone. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Fri, Apr 12, 2013 at 1:20 PM, Maxim Kammerer wrote: > On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger wrote: >> i don't know what you mean. if the ebuild detects devpts being mounted and >> the mount is incorrect, it will die. if you don't have devpts mounted at >> all, >> then it assumes you know what you're doing. > > What I am saying is that you make no distinction between build > environment and deployment environment. Quite a few users build their > Gentoo systems in a chroot. In that case, whole /dev, or its portions > (including /dev/pts) can be bind-mounts from the host filesystem, and > /dev/pts does not need to have the correct permissions. However, you > *would* see such a bind-mount as a devpts mount in /proc/mounts. So > why not print a warning — what's the point of dying in pkg_preinst? > Do you have a reason for not having /dev/pts mounted with gid=5 on the system hosting the chroot environment? Calling die is much more likely to save users systems than an ewarn.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger wrote: > i don't know what you mean. if the ebuild detects devpts being mounted and > the mount is incorrect, it will die. if you don't have devpts mounted at all, > then it assumes you know what you're doing. What I am saying is that you make no distinction between build environment and deployment environment. Quite a few users build their Gentoo systems in a chroot. In that case, whole /dev, or its portions (including /dev/pts) can be bind-mounts from the host filesystem, and /dev/pts does not need to have the correct permissions. However, you *would* see such a bind-mount as a devpts mount in /proc/mounts. So why not print a warning — what's the point of dying in pkg_preinst? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Friday 12 April 2013 02:50:20 Maxim Kammerer wrote: > On Wed, Apr 10, 2013 at 8:15 AM, Mike Frysinger wrote: > > i plan on updating the latest glibc to add USE=suid. in pkg_preinst and > > ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. > > if it doesn't find one, i'll have it call `die`. > > What about chroot builds? I have /dev/pts bind-mounted from the (old) > host filesystem into chroot, yet pt_chown has its suid bit happily > disabled in deployed build since long time ago. i don't know what you mean. if the ebuild detects devpts being mounted and the mount is incorrect, it will die. if you don't have devpts mounted at all, then it assumes you know what you're doing. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Wed, Apr 10, 2013 at 8:15 AM, Mike Frysinger wrote: > i plan on updating the latest glibc to add USE=suid. in pkg_preinst and > ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if > it doesn't find one, i'll have it call `die`. What about chroot builds? I have /dev/pts bind-mounted from the (old) host filesystem into chroot, yet pt_chown has its suid bit happily disabled in deployed build since long time ago. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Thursday 11 April 2013 11:43:59 James Cloos wrote: > > "MF" == Mike Frysinger writes: > MF> this should impact very few (if any) > MF> users, so i don't think a news item makes sense. > > It will impact everyone who has /dev/pts in fstab(5). don't do that. delete the line. > I doubt that any say gid=5. > > I don't remember why this box has it in fstab; it looks like it always did. > > The backup of my (now dead) laptop also has such an entry. The rcs log > for that one shows that it got added in late '03, and not manually. baselayout has not included devpts in /etc/fstab since 26 Nov 2001 and even then, it was commented out http://sources.gentoo.org/baselayout/branches/baselayout-1_12/etc/fstab?view=log http://sources.gentoo.org/baselayout/branches/rc- scripts-1_6/etc/fstab?view=log the oldest tag we have is baselayout-1.11.15 (released 22 Apr 2006), and it doesn't include it. the oldest tarball i have is baselayout-1.11.8 (released 15 Dec 2004) as that's when i took over releasing things, and it doesn't include it either. it hasn't been added since that release. so i stand by my statement that very few people will be impacted by this. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
> "MF" == Mike Frysinger writes: MF> this should impact very few (if any) MF> users, so i don't think a news item makes sense. It will impact everyone who has /dev/pts in fstab(5). I doubt that any say gid=5. I don't remember why this box has it in fstab; it looks like it always did. The backup of my (now dead) laptop also has such an entry. The rcs log for that one shows that it got added in late '03, and not manually. I imagine therefore that it is not all that uncommon. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Wednesday 10 April 2013 14:56:26 Rich Freeman wrote: > On Wed, Apr 10, 2013 at 1:15 AM, Mike Frysinger wrote: > > tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things > > will happen and it's (probably) all your fault > > So, who is this directed to? any dev who maintains systems that handle initial mounting, or knows of random edge cases in the tree that might run into this. i can't exactly grep our entire code base looking for devpts mounters. > If this is to anybody who uses Gentoo, > then at best this should be a place to hash out the contents of the > news item. We don't expect Gentoo users to read -dev. users will be informed of the problem when the ebuild fails and then can trivially resolve it at that point. this should impact very few (if any) users, so i don't think a news item makes sense. > Certainly the > maintainers of anything that mounts /dev/pts > (OpenRC/SystemD/baselayout?) should take heed. the maintainers are reading -dev -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On Wed, Apr 10, 2013 at 1:15 AM, Mike Frysinger wrote: > tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things will > happen and it's (probably) all your fault So, who is this directed to? If this is to anybody who uses Gentoo, then at best this should be a place to hash out the contents of the news item. We don't expect Gentoo users to read -dev. Certainly the maintainers of anything that mounts /dev/pts (OpenRC/SystemD/baselayout?) should take heed. Rich
Re: [gentoo-dev] glibc: pt_chown setuid going away by default
On 4/9/13 10:15 PM, Mike Frysinger wrote: > i plan on updating the latest glibc to add USE=suid. in pkg_preinst and > ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if > it doesn't find one, i'll have it call `die`. if the bsd pty scenario wasn't > long dead, and the devpts option didn't have gid=/mode= options, then it > might > be reasonable to have it warn and do `chmod +s`. but i can't think of any > legitimate reasons for not using devpts & mounting it correctly. this is the > right answer even in the embedded world. +1 I have it disabled already on some of my systems using suidctl. I was going to suggest making that change some time ago - great to hear it's being done. Thanks for working on this! Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] glibc: pt_chown setuid going away by default
tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things will happen and it's (probably) all your fault when you run grantpt(), glibc attempts to set up your pty with correct ownership & permissions. it does so by executing a setuid helper called pt_chown as needed. we all know setuid==bad, so let's do something about it. this system is a throw back to the bad old bsd pty days where you had a ton of pre-allocated nodes in /dev/ named pty??. since the user has requested a new pty, the system had to make sure it had correct permissions before giving it back (it might be the default of root:root, or it might have the previous user's settings which would be super bad). this system sucks for many reasons. with Linux, we have devpts mounted at /dev/pts/ which provides dynamic UNIX 98 ptys via the /dev/ptmx control node. the kernel knows that when you request a new pty, the sane thing is to set the default uid/gid to your own process's uid/gid. it even goes further and allows you to specify (at mount time) default gid/permissions. with openrc (and in baselayout-1.12, but i'm pretty sure it's been this way for even longer), our default mount uses gid=5 (the tty group) and mode=620 (what we want). that means when a new pty is requested, the kernel automatically sets the ownership of the new file to the process's uid and the mounted group setting (tty), as well as setting the perms to 620. back to glibc, when you call grantpt(), it checks the current uid/gid/mode. if they all match what it expects (and it should with our default devpts mount opts), it returns w/out doing any real work (like calling the setuid pt_chown helper). that means this binary is sitting around with setuid perms for no good reason. i plan on updating the latest glibc to add USE=suid. in pkg_preinst and ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5. if it doesn't find one, i'll have it call `die`. if the bsd pty scenario wasn't long dead, and the devpts option didn't have gid=/mode= options, then it might be reasonable to have it warn and do `chmod +s`. but i can't think of any legitimate reasons for not using devpts & mounting it correctly. this is the right answer even in the embedded world. -mike signature.asc Description: This is a digitally signed message part.
