Re: sem_open(2) and ENAMETOOLONG

[Kamil Rytarowski <n54%gmx.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23.04.2016 20:55, David Holland wrote:
> 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 don't know any reason besides saving extra bytes of memory.

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

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

I see.

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

I see, so I think pathconf(2) or similar check is preferred.

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

I'm fine with 14 characters here... but checking the kernel code for
limit isn't convenient.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXG95LAAoJEEuzCOmwLnZshDkQAJgz2ufN7MsAUN5TPq5RM9l/
4bln7dwkXlf/d/C6wNtJI4u26a7R2GTRWHsQkXTYH5uK/JtJuMMET9pXD+xiLfoY
EVDc4zfQ7wEMReGkFGfcEhZdkFeUyivaoCEnFAr0wDuc/q74T00AxHXOGPTkKyFx
zfEIvoxig3QS1BcM9DuBms3LxtfyuCiCG9CLZSs+ouoKswu6BYsBEaoGiUslDrPH
ThnRdnBzxyLpUwIVBnC17a0spLs9FXaxRxLfR2PLfM1UnwG2E50bkPp4enqwyVdy
Z6FaKYAl3V/8GlLBZeF83WpgFczwlx9br+aBQEGQFDj+HOUhIoGw9dZT+iiKSr/Q
kbKCLoac110C4idapcDRtb31ZYxm9oa7on6xkK9Mi21+g2wW2Tq/x+nZohXXKn0i
EO/td8UMeyZcbXBfairT1TWXqMwuEf7I9uv3HzZpnY6nmYeBlggCzmw6LUBIlYPt
0jNE7cmLcuYy1BN9EW5jOh/m8KpXGDuGKwUtsiehlq7bUe1bQ2qvOaimIyhFfbSI
VKOTWYth/ctCcne+Ppe6IzSirAWYKTZLBa8RzyS87H3tR7P2+jlg2TERmeqmI+vT
maTvPqto5Cm1l40YrBYYuOU0fOm1fmJ4B35bKILF7iCJrcT42bXTO6H0yW47nftG
FuCuhsCRSKJIuguDbvFf
=jGG8
-----END PGP SIGNATURE-----