Re: sem_open(2) and ENAMETOOLONG

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Apr 23, 2016 at 10:42:52PM +0200, Kamil Rytarowski wrote:
 > >> I read in the POSIX resources that the limit is defined by
 > >> PATH_MAX or its variation:
 > >> 
 > >> ENAMETOOLONG The length of the name argument exceeds {PATH_MAX}
 > >> or a pathname component is longer than {NAME_MAX}.
 > > 
 > > Wait, are sem_open() names names (single components) or whole
 > > paths? I thought they were single components.
 > 
 > There are possible limits for whole paths and components. NetBSD keeps
 > 14 for the whole name.

That wasn't the question -- the question is what the semantics of
sem_open() names are supposed to be.

The code we have will return EINVAL if the name contains anything
other than a leading slash. Therefore, NAME_MAX seems to be the
applicable limit.

 > >> If so, could we export SEM_MAX_NAMELEN to userland header.
 > > 
 > > let's not; it just encourages code that does
 > > 
 > > char name[SEM_MAX_NAMELEN+1];
 > > 
 > > that makes it impossible to safely raise the limit later.
 > 
 > I see, so I think pathconf(2) or similar check is preferred.

Currently there isn't such a check that can return SEM_MAX_NAMELEN.
Best bet is to use NAME_MAX (or PATH_MAX) for buffers you might want
to put semaphore names in, but avoid generating long ones yourself.

 > >> Additionally I noted that SEM_VALUE_MAX is defined at least twice
 > >> in the code-base, in <semaphore.h> and sys/kern/uipc_sem.c
 > >> (thankfully with the same value: ~0U).
 > > 
 > > That would be a bug.

namely: please fix :-)

 > >> FreeBSD seems to respect the PATH_MAX property of the name
 > >> argument:
 > >> 
 > >> sem_t * _sem_open(const char *name, int flags, ...) { char
 > >> path[PATH_MAX];
 > > 
 > > Never put a value of size PATH_MAX on the kernel stack...
 > > 
 > > I don't see any overt reason not to raise the limit to NAME_MAX, 
 > > though. Seems to be just a matter of how much kernel memory the
 > > names are allowed to use.
 > 
 > I'm fine with 14 characters here... but checking the kernel code for
 > limit isn't convenient.

Well, it seems reasonable to raise the limit. I have now checked
carefully and there's no reason the limit can't be raised to any value
such that a temporary name buffer can still reasonably be placed on
the kernel stack.

I also noticed that if you read() one of these semaphores you get the
name back... including a null terminator. Where (if anywhere) is the
read behavior documented, and is it supposed to include the null
terminator or not?

-- 
David A. Holland
dholland%netbsd.org@localhost