This patch has the kernel internally create the [ptmx, c, 5:2] device
when mounting devpts filesystem. The permissions for the device node
can be specified by the '-o ptmx_mode=0666' option. The default mode
is 0666.
NAK
Hopefully, presence of the 'ptmx' node in /dev/pts does not
Alan Cox wrote:
This patch has the kernel internally create the [ptmx, c, 5:2] device
when mounting devpts filesystem. The permissions for the device node
can be specified by the '-o ptmx_mode=0666' option. The default mode
is 0666.
NAK
Hopefully, presence of the 'ptmx' node in
auto-created, than supporting mknod(2) inside the devpts filesystem.
It's not a matter of changing the user space; it's a matter of what
makes most sense inside the kernel.
Having an extra node with different permissions suddenely appear without
warning isn't I think good behaviour. I'm open
Alan Cox wrote:
auto-created, than supporting mknod(2) inside the devpts filesystem.
It's not a matter of changing the user space; it's a matter of what
makes most sense inside the kernel.
Having an extra node with different permissions suddenely appear without
warning isn't I think good
Quoting H. Peter Anvin ([EMAIL PROTECTED]):
Alan Cox wrote:
auto-created, than supporting mknod(2) inside the devpts filesystem.
It's not a matter of changing the user space; it's a matter of what
makes most sense inside the kernel.
Having an extra node with different permissions
That makes sense. But if Suka does that, then is creating the device
when the newns flag is specified ok with you, Alan?
Sounds a good basis yes.
___
Containers mailing list
[EMAIL PROTECTED]
H. Peter Anvin [EMAIL PROTECTED] wrote:
Alan Cox wrote:
auto-created, than supporting mknod(2) inside the devpts filesystem. It's
not a matter of changing the user space; it's a matter of what makes
most sense inside the kernel.
Having an extra node with different permissions suddenely
[EMAIL PROTECTED] wrote:
I had the new ptmx node only in 'multi-mount' mode initially. But if users
want the multi-mount semantics, /dev/ptmx must be a symlink. If its a symlink,
we break in the single-mount case (which does not have the ptmx node and
we don't support mknod in pts).
True,
[EMAIL PROTECTED] writes:
H. Peter Anvin [EMAIL PROTECTED] wrote:
Alan Cox wrote:
auto-created, than supporting mknod(2) inside the devpts filesystem. It's
not a matter of changing the user space; it's a matter of what makes
most sense inside the kernel.
Having an extra node with
Eric W. Biederman wrote:
I had the new ptmx node only in 'multi-mount' mode initially. But if users
want the multi-mount semantics, /dev/ptmx must be a symlink. If its a
symlink,
we break in the single-mount case (which does not have the ptmx node and
we don't support mknod in pts).
Then
H. Peter Anvin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I had the new ptmx node only in 'multi-mount' mode initially. But if users
want the multi-mount semantics, /dev/ptmx must be a symlink. If its a
symlink,
we break in the single-mount case (which does not have the ptmx node and
[EMAIL PROTECTED] wrote:
Hmm, so, single and multi-mount don't coexist ? i.e some are multi-mounts
while others are single-mounts.
The way I looked at is that even if a distro has not yet updated the
startup script (fstab), we could use the multi-mount. Maybe a container
startup script
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I had the new ptmx node only in 'multi-mount' mode initially. But if users
want the multi-mount semantics, /dev/ptmx must be a symlink. If its a
symlink,
we break in the single-mount case (which does not have the ptmx node and
Eric W. Biederman wrote:
The point of making it a bind is to address the concerns about
backwards compatibility in user space. In particular security
conscious applications and applications that perform sanity checks
are known to ignore things if they are the wrong type in the filesystem.
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
H. Peter Anvin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I had the new ptmx node only in 'multi-mount' mode initially. But if users
want the multi-mount semantics, /dev/ptmx must be a symlink. If its a
symlink,
we break in the
15 matches
Mail list logo
