linux-kernel - devpts multiple instances feedback

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090103155209.GA17988@lst.de>
Date:	Sat, 3 Jan 2009 16:52:09 +0100
From:	Christoph Hellwig <hch@....de>
To:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: devpts multiple instances feedback

I just took a look at the changes going into Linus current tree and
here's some feedback about the devpts multiple instances code:

 - the ptmx node is quite useful, I think it should always be around,
   even for normal devpts mounts.  That way distros can slowly migrate
   over to just using it by default and making the containers
   interaction easier.  It's also in many ways much nicer to have
   all the pty handling in one filesystems instead of sometimes
   using the character device.
 - the 000 mode is very weird, given how the /dev/ptmx operates
   it doesn't really make much sense to have it different than 0666
   unless you want to disable ptys.
 - why does pts_sb_from_inode have to check s_magic, I can't see
   it ever used on an inode not from the devpts filesystem
 - parsing the options twice is rather odd, I'd rather parse it into
   a once allocated structure then passed on through the private
   data void pointer into get_sb_nodev
 - creating the ptmx node should happen inside devfs_fill_super
 - once the ptmx mknod is gone I think new_pts_mount,
   is_new_instance_mount, init_pts_mount and maybe even get_init_pts_sb
   should be merged into devpts_get_sb to make the whole mounting
   scenario easier to follow instead of having to jump through half
   a dozen functions
 - I think CONFIG_DEVPTS_MULTIPLE_INSTANCES is not a good idea,
   it's not much code and could either be enabled unconditionally or
   based on the presence of a generic namespaces config option.
   (btw, this also applies to the other namespaces options, there's
   not much of a reason to have millions of options for them,
   one single option would be a lot easier for the user..)
--
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/