Re: sem_open(2) and ENAMETOOLONG

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

On Sat, Apr 23, 2016 at 06:06:10PM +0200, Kamil Rytarowski wrote:
 > The sem_open(2) function call reports an error for a too long name and
 > sets errno:
 > 
 > [ENAMETOOLONG]     The name argument is too long.

...as it should.

 > The limit is held privately in the kernel:
 > 
 > sys/kern/uipc_sem.c:#define     SEM_MAX_NAMELEN         14

Ugh, that's not really long enough. Is there any reason for this limit
or is it just a copy of a (very) historical value for NAME_MAX?

 > 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.

In any event, you have to call pathconf() to get the actual name limit
for any particular volume. Not sure how you do that with the "volume"
used by sem_open, though.

 > Is our code compliant?

dunno.

 > 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.

 > 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.

 > 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.

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