Since the issue of PTY namespaces came up (and was rejected) back in
April, I have thought a little bit about changing ptys to be tied
directly into a devpts instance. devpts would then be a "normal"
filesystem, which can be mounted multiple times (or not at all). pty's
would then become private to a devpts instance.
This is what it would appear would have to change, and I'd like to get
people's feeing for the user-space impact:
1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
2. Permissions on /dev/ptmx would not be persistent, and would have to
be set via devpts mount options (unless they're 0666 root.tty, which
would presumably be the default.)
3. The /proc/sys/kernel/pty limit would be global; a per-filesystem
limit could be added on top or instead (presumably via a filesystem
mount options.)
I worry #1 would have substantial user-space impact, but I don't see a
way around it, since there would be no obvious way to associate
/dev/ptmx with a filesystem.
-hpa
On Fri, 2008-08-01 at 11:12 -0700, H. Peter Anvin wrote:
> 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
...
> I worry #1 would have substantial user-space impact, but I don't see a
> way around it, since there would be no obvious way to associate
> /dev/ptmx with a filesystem.
Are your worries just about replacing what is now a normal file with a
symlink, and the behavioral changes that come with that?
I wonder if using a bind mount for the file would be more robust. We
wouldn't, of course, be able to do it persistently, but I bet it would
be something we could count on udev to do for us.
-- Dave
On Fri, Aug 01, 2008 at 12:23:44PM -0700, Dave Hansen wrote:
> On Fri, 2008-08-01 at 11:12 -0700, H. Peter Anvin wrote:
> > 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
> ...
> > I worry #1 would have substantial user-space impact, but I don't see a
> > way around it, since there would be no obvious way to associate
> > /dev/ptmx with a filesystem.
>
> Are your worries just about replacing what is now a normal file with a
> symlink, and the behavioral changes that come with that?
>
> I wonder if using a bind mount for the file would be more robust. We
> wouldn't, of course, be able to do it persistently, but I bet it would
> be something we could count on udev to do for us.
Not on my boxen. However, devpts tends to be mounted by initscripts,
which is where one would naturally do that.
Dave Hansen wrote:
> On Fri, 2008-08-01 at 11:12 -0700, H. Peter Anvin wrote:
>> 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
> ...
>> I worry #1 would have substantial user-space impact, but I don't see a
>> way around it, since there would be no obvious way to associate
>> /dev/ptmx with a filesystem.
>
> Are your worries just about replacing what is now a normal file with a
> symlink, and the behavioral changes that come with that?
>
> I wonder if using a bind mount for the file would be more robust. We
> wouldn't, of course, be able to do it persistently, but I bet it would
> be something we could count on udev to do for us.
No, I'm concerned about the changes needed for udev and setup scripts.
-hpa
My apologies, I accidentally hit "reply" instead of "reply all" and
this got sent only to Peter.
On Fri, Aug 1, 2008 at 2:12 PM, H. Peter Anvin <[email protected]> wrote:
> This is what it would appear would have to change, and I'd like to get
> people's feeing for the user-space impact:
>
> 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
> 2. Permissions on /dev/ptmx would not be persistent, and would have to
> be set via devpts mount options (unless they're 0666 root.tty, which
> would presumably be the default.)
> 3. The /proc/sys/kernel/pty limit would be global; a per-filesystem
> limit could be added on top or instead (presumably via a filesystem
> mount options.)
Here's my suggestion:
By default, without any mount options, use the current "legacy"
behavior. The devpts filesystem would point to a "global" instance on
the whole box, controlled by the traditional /dev/ptmx device node.
There would *NOT* be a /dev/pts/ptmx node.
If the devpts filesystem is mounted with a special option ("permount"?
"noglobal"?), then it will create a new devpts instance associated
with the filesystem. A devpts mounted that way *WILL* have a magic
/dev/pts/ptmx node.
If the kernel is built with CONFIG_DEVPTS_FORCE_PERMOUNT then the
traditional /dev/ptmx device node will be neutered (IE: always return
-ENODEV) and the "permount" option will be forced for all devpts
mounts. This will also remove the static global devpts instance.
Once distros add the ptmx=>pts/ptmx symlink and validate their
software they can turn on that config option and be able to safely
virtualize /dev/pts.
For the distros which don't, sysadmins can easily patch their own udev
and init scripts to turn on the "permount" option and set up the ptmx
symlink, although child namespaces will still theoretically be able to
get outside of their namespace through the mostly-unused global devpts
instance.
Cheers,
Kyle Moffett
On Fri, Aug 01, 2008 at 11:12:21AM -0700, H. Peter Anvin wrote:
> 2. Permissions on /dev/ptmx would not be persistent, and would have to
> be set via devpts mount options (unless they're 0666 root.tty, which
> would presumably be the default.)
On Debian based systems /dev/ptmx is 0666 root.root. But the gid of tty
is already supplied for devpts.
> I worry #1 would have substantial user-space impact, but I don't see a
> way around it, since there would be no obvious way to associate
> /dev/ptmx with a filesystem.
Hmm. Several possibilities:
- Change the filesysteme name and the old name remains usable with
/dev/ptmx.
Problem: You could mount the filesystem with the old name within a
container.
- Make the first mounted one special.
Problem: Will not survive a umount/mount cycle. But this would be not
the case anyway.
But you are sure, none of them is a pretty solution.
Bastian
--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
Kyle Moffett wrote:
>
> Here's my suggestion:
>
> By default, without any mount options, use the current "legacy"
> behavior. The devpts filesystem would point to a "global" instance on
> the whole box, controlled by the traditional /dev/ptmx device node.
> There would *NOT* be a /dev/pts/ptmx node.
>
> If the devpts filesystem is mounted with a special option ("permount"?
> "noglobal"?), then it will create a new devpts instance associated
> with the filesystem. A devpts mounted that way *WILL* have a magic
> /dev/pts/ptmx node.
>
> If the kernel is built with CONFIG_DEVPTS_FORCE_PERMOUNT then the
> traditional /dev/ptmx device node will be neutered (IE: always return
> -ENODEV) and the "permount" option will be forced for all devpts
> mounts. This will also remove the static global devpts instance.
>
Hm. This might work if we can get the mount behaviour to work right.
I'll think about it. It definitely seems like a reasonable way to get
from A to B.
-hpa
H. Peter Anvin [[email protected]] wrote:
> Since the issue of PTY namespaces came up (and was rejected) back in April,
> I have thought a little bit about changing ptys to be tied directly into a
> devpts instance. devpts would then be a "normal" filesystem, which can be
> mounted multiple times (or not at all). pty's would then become private to
> a devpts instance.
Sorry, I thought we were going with a complete device namespace - since that
would address other devices as well and would avoid the following user-space
issue.
I guess this issue came up in OLS recently and have been looking into this
again. I have some helper patches to explore multiple mounts of devpts
without namespace stuff and can send them out in a couple of days.
>
> This is what it would appear would have to change, and I'd like to get
> people's feeing for the user-space impact:
>
> 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
IIRC, /dev/tty also needs a similar symlink.
> 2. Permissions on /dev/ptmx would not be persistent, and would have to
> be set via devpts mount options (unless they're 0666 root.tty, which
> would presumably be the default.)
> 3. The /proc/sys/kernel/pty limit would be global; a per-filesystem
> limit could be added on top or instead (presumably via a filesystem
> mount options.)
>
> I worry #1 would have substantial user-space impact, but I don't see a way
> around it, since there would be no obvious way to associate /dev/ptmx with
> a filesystem.
Sukadev
[email protected] wrote:
>
> IIRC, /dev/tty also needs a similar symlink.
>
Why? I do not believe that is correct.
-hpa
> > 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
>
> IIRC, /dev/tty also needs a similar symlink.
Making them symlinks is asking for trouble because some code does go
around using stat and the like and tools like MAKEDEV have definite ideas.
For /dev/tty the definition is precisely that it is your controlling
tty. No reference to namespace and a task whose controlling tty is in a
different namespace should still open the controlling tty not some
parallel in another universe when you open /dev/tty.
If you want to make sure the controlling tty is in the right namespace
that can be done in userspace when transferring control into a namespace.
In many cases I doubt that is even what is wanted.
> > 2. Permissions on /dev/ptmx would not be persistent, and would have to
> > be set via devpts mount options (unless they're 0666 root.tty, which
> > would presumably be the default.)
> > 3. The /proc/sys/kernel/pty limit would be global; a per-filesystem
> > limit could be added on top or instead (presumably via a filesystem
> > mount options.)
> >
> > I worry #1 would have substantial user-space impact, but I don't see a way
> > around it, since there would be no obvious way to associate /dev/ptmx with
> > a filesystem.
/dev/tty and /dev/ptmx already primarily operate by identifying a device
and switching the work to that. Actually putting a bit of namespace logic
in the driver code so the actual files stay as expected (device nodes
etc) seems a *lot* simpler than trying to do symlink hacks.
Alan
Alan Cox [[email protected]] wrote:
| > > 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
| >
| > IIRC, /dev/tty also needs a similar symlink.
|
| Making them symlinks is asking for trouble because some code does go
| around using stat and the like and tools like MAKEDEV have definite ideas.
|
| For /dev/tty the definition is precisely that it is your controlling
| tty. No reference to namespace and a task whose controlling tty is in a
| different namespace should still open the controlling tty not some
| parallel in another universe when you open /dev/tty.
Well, I thought the problem was something like this:
If /dev/pts/1 is the controlling terminal and there are multiple mounts
of devpts, when we open /dev/tty, kernel would somehow have to find the
right instance of devpts.
When init_dev() calls devpts_get_tty(), it would need to specify the devpts
instance. So tty_open() of "/dev/tty" would somehow have to find it based on
the /dev/tty inode (which could be in ext3).
(I thought the issue was similar with /dev/ptmx, ptmx allocates a new
index, /dev/tty accesses an existing index, but both need to somehow
find the right pts instance -no ?)
|
| If you want to make sure the controlling tty is in the right namespace
| that can be done in userspace when transferring control into a namespace.
| In many cases I doubt that is even what is wanted.
|
| > > 2. Permissions on /dev/ptmx would not be persistent, and would have to
| > > be set via devpts mount options (unless they're 0666 root.tty, which
| > > would presumably be the default.)
| > > 3. The /proc/sys/kernel/pty limit would be global; a per-filesystem
| > > limit could be added on top or instead (presumably via a filesystem
| > > mount options.)
| > >
| > > I worry #1 would have substantial user-space impact, but I don't see a way
| > > around it, since there would be no obvious way to associate /dev/ptmx with
| > > a filesystem.
|
| /dev/tty and /dev/ptmx already primarily operate by identifying a device
| and switching the work to that. Actually putting a bit of namespace logic
| in the driver code so the actual files stay as expected (device nodes
| etc) seems a *lot* simpler than trying to do symlink hacks.
|
| Alan
> If /dev/pts/1 is the controlling terminal and there are multiple mounts
> of devpts, when we open /dev/tty, kernel would somehow have to find the
> right instance of devpts.
current->tty - it is a direct internal reference.
Alan