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