request: increase TTY_NAME_MAX in limits.h

request: increase TTY_NAME_MAX in limits.h

[Laurent Bercot]

  Hello,

  TTY_NAME_MAX is currently 20. This is not enough for me. Could it
be increased a bit ?

  Explanation: my /dev is actually a symlink to /mnt/tmpfs/dev, and
ttyname_r() writes fully resolved paths, so "/mnt/tmpfs/dev/pts/0"
is *just* too large to fit into the 20 bytes static buffer provided
by ttyname().
  Impact: it breaks dropbear, which instantly dies when ttyname() fails -
this is a deal breaker for me. Less importantly, it also breaks the %y%
prompt mechanism in zsh, which prints the default "tty" instead of the
correct name.

I'd like to be able to use prebuilt musl toolchains, like Gregor's ones,
or Rob's ones when they come out, so editing limits.h myself won't cut it.
24 bytes would be enough for me to have 10k ptys (which will never happen).
So... can I haz 4 more bytes plz ?

  Thanks,

-- 
  Laurent

Re: request: increase TTY_NAME_MAX in limits.h

[Rich Felker]

On Sat, Nov 09, 2013 at 11:07:32AM +0000, Laurent Bercot wrote:
>  Hello,
> 
>  TTY_NAME_MAX is currently 20. This is not enough for me. Could it
> be increased a bit ?

The only thing that needs to be checked is if there are any places
where increasing the value could cause buffer overflows (in an
existing binary already compiled with the value of 20). A casual
glance does not show any such issues.

>  Explanation: my /dev is actually a symlink to /mnt/tmpfs/dev, and
> ttyname_r() writes fully resolved paths, so "/mnt/tmpfs/dev/pts/0"
> is *just* too large to fit into the 20 bytes static buffer provided
> by ttyname().
>  Impact: it breaks dropbear, which instantly dies when ttyname() fails -
> this is a deal breaker for me. Less importantly, it also breaks the %y%
> prompt mechanism in zsh, which prints the default "tty" instead of the
> correct name.

Understood.

> I'd like to be able to use prebuilt musl toolchains, like Gregor's ones,
> or Rob's ones when they come out, so editing limits.h myself won't cut it.
> 24 bytes would be enough for me to have 10k ptys (which will never happen).
> So... can I haz 4 more bytes plz ?

If we change it I think we might as well go with the glibc value of 32
rather than just increasing it by 4.

Rich

Re: request: increase TTY_NAME_MAX in limits.h

[Laurent Bercot]

> If we change it I think we might as well go with the glibc value of 32
> rather than just increasing it by 4.

  That would be great, thanks :)

  I'm honestly surprised that those buffers are so small, even in glibc.
Sure, it takes up static space, and in practice a small value works for
most people since it will usually be /dev/something, but since ttyname()
is not supposed to ever fail with ERANGE or any kind of overflow, I was
expecting the buffer to be PATH_MAX bytes. Or even dynamically (re)allocated -
which would pull in malloc(), but text space + a bit of heap space is cheaper
than static space.

-- 
  Laurent

Re: request: increase TTY_NAME_MAX in limits.h

[Rich Felker]

On Sat, Nov 09, 2013 at 05:20:35PM +0000, Laurent Bercot wrote:
> 
> >If we change it I think we might as well go with the glibc value of 32
> >rather than just increasing it by 4.
> 
>  That would be great, thanks :)
> 
>  I'm honestly surprised that those buffers are so small, even in glibc.
> Sure, it takes up static space, and in practice a small value works for
> most people since it will usually be /dev/something, but since ttyname()
> is not supposed to ever fail with ERANGE or any kind of overflow, I was
> expecting the buffer to be PATH_MAX bytes. Or even dynamically (re)allocated -
> which would pull in malloc(), but text space + a bit of heap space is cheaper
> than static space.

I'm not sure exactly what glibc does; technically, there's no reason
the size of this internal buffer needs to match TTY_NAME_MAX. I just
chose that as a natural size for it. On most systems, where the
ttyname is /dev/xxxxx or /dev/pts/xxxxx, 20 should be sufficient and
32 should leave plenty room. Your situation is a bit odd but there's
no sense in gratuitously breaking it.

Rich

Re: request: increase TTY_NAME_MAX in limits.h

[Rob Landley]

On 11/09/2013 11:38:42 AM, Rich Felker wrote:
> On Sat, Nov 09, 2013 at 05:20:35PM +0000, Laurent Bercot wrote:
> >
> > >If we change it I think we might as well go with the glibc value  
> of 32
> > >rather than just increasing it by 4.
> >
> >  That would be great, thanks :)
> >
> >  I'm honestly surprised that those buffers are so small, even in  
> glibc.
> > Sure, it takes up static space, and in practice a small value works  
> for
> > most people since it will usually be /dev/something, but since  
> ttyname()
> > is not supposed to ever fail with ERANGE or any kind of overflow, I  
> was
> > expecting the buffer to be PATH_MAX bytes. Or even dynamically  
> (re)allocated -
> > which would pull in malloc(), but text space + a bit of heap space  
> is cheaper
> > than static space.
> 
> I'm not sure exactly what glibc does; technically, there's no reason
> the size of this internal buffer needs to match TTY_NAME_MAX.

If they're doing an absolute path, I note that the way ttys work in lxc  
containers with devtmpfs is something like:

   mkdir /dev/.lxc/$CONTAINER
   ln /dev/$DEVICE /dev/.lxc/$CONTAINER/
   mount --bind /dev/.lxc/$CONTAINER $CONTAIN_DIR/dev

(With a caveat that the tty devices are generally half a pty talking to  
process on the host, and maybe /dev/console is a fifo or something.)

In the container side, they'll presumably see /dev/thingy as usual, but  
from the host side if you query one of those ttys and it does an  
absolute path into a fixed length buffer, depending on how long the  
container name is...)

My point is that if the idea is "uniquely identify this device", the  
result isn't necessarily going to be "absolute path to where the node  
currently actually lives".

Rob