| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 Jan 2012 00:27:24 +0100 From: Kay Sievers <kay.sievers@...y.org> To: Serge Hallyn <serge.hallyn@...onical.com> Cc: "Serge E. Hallyn" <serge@...lyn.com>, containers@...ts.linux-foundation.org, Dave Hansen <haveblue@...ibm.com>, linux-kernel@...r.kernel.org, "Eric W. Biederman" <ebiederm@...ssion.com>, Andy Whitcroft <apw@...onical.com>, sukadev@...ux.vnet.ibm.com, Linus Torvalds <torvalds@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk> Subject: Re: [RFC] fix devpts mount behavior On Wed, Jan 25, 2012 at 00:16, Serge Hallyn <serge.hallyn@...onical.com> wrote: > Quoting Kay Sievers (kay.sievers@...y.org): >> On Tue, Jan 24, 2012 at 23:02, Serge E. Hallyn <serge@...lyn.com> wrote: >> > Quoting Eric W. Biederman (ebiederm@...ssion.com): >> >> >> It looks like relatively recent udev still creates /dev/ptmx and does >> > >> > Boy, it does, and it's stubborn about it. Removing the /lib/udev/rules.d >> > entry doesn't stop it. (this is after I've had an init job replace the >> > devtmpfs-created ptmx entry with a symlink) >> >> Udev has nothing to do with that. The kernel creates that device node. >> Udev does not carry any rules you could remove, to name device nodes, >> it only set permissions and creates symlinks to device nodes. > > That's odd, because I was sure I deleted the node after the kernel created > it. > > But it sounds like I must have done it wrong. Oh, older udevs re-create it when you run 'udevadm trigger', but only then, never on its own, there will be no such event. Current udevs will not do mknod() anymore, never. >> It will never replace a kernel-created device node with a symlink, >> there is no way to express that. If you don't want a device node >> there, you need to change the kernel, to not export >> /sys/class/tty/ptmx/ the way it is today. >> >> > So current distros (well, Ubuntu and Fedora at least) would need to at least >> > (a) fix udev, >> >> To do what? > > Nothing, as I'm sure you're right above :) :) >> > (b) change the default devpts mount (done from initramfs) to >> > add ptmxmode=666, >> >> > (c) (if not done in udev) create the /dev/ptmx symlink. >> >> Udev can only create symlinks to devices the driver-core creates, not >> to devices inside a custom filesystem. > > I see. > >> > For safety I'd recommend creating /dev/pts/ptmx with >> > DEVPTS_MULTIPLE_INSTANCES=n (or dropping that support), and by default >> > setting ptmxmode to 666 as that's what udev does. >> >> The mode for ptmx is set by the kernel itself, and does not even need >> udev to do that: >> $ cat /sys/class/tty/ptmx/uevent >> MAJOR=5 >> MINOR=2 >> DEVNAME=ptmx >> DEVMODE=0666 > > That has nothing to do with /dev/pts/ptmx, whose perms are set based on > the '-o ptmxmode=" argument, and default to 000 if not specified. Yeah, right. Just saying that some permissions are set by the kernel itself these days. I wouldn't be bad if the kernel had the default of 0666 for the devpts fs, would it? > If /dev/ptmx is going to be a symlink to /dev/pts/ptmx, then we have to set > the /dev/pts/ptmx perms to not be 000, or users won't be able to create > ptys. Right. Change the devpts in-kernel default? We might also thing about changing /sys/class/tty/ptmx/, and have the kernel create the symlink? The loops through userspace to setup default kernel stuff are kind of crazy ... Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists