Re: does numeric only name of jails not allowed (bug?)

Hello, Kyle.

>> I think to prevent ambiguity there must be a possibility or requirement to quote jail name to force interpretation as a string.
>> Using "47777" instead of 47777 doesn't help for now.
>> 

> What ambiguity are you referring to here?  In context it's pretty 
> unambiguous, the name is the thing that appears before an opening brace.

For  me 47777 is a hexadecimal number (there is also a32b1 which works
well).   I  want  it  to be the name of a jail (processed as a string)
without any relation to jid.

But 47777 may  be recognized as a decimal number also and, consequently,
will be used as a jid and a name.



On 9 августа 2025 г., 16:30:32 you wrote:

> On 8/9/25 06:01, Anthony Pankov wrote:
>> Hello Kyle,
>> 
>>> This is an artifact of how numeric names work.  When you use a purely numeric name, it's taken as both the jid and the name.  jail(8) has some logic up-front that will set one or the other variable based on the name, but it omits the other.
>> 
>> I think to prevent ambiguity there must be a possibility or requirement to quote jail name to force interpretation as a string.
>> Using "47777" instead of 47777 doesn't help for now.
>> 

> What ambiguity are you referring to here?  In context it's pretty 
> unambiguous, the name is the thing that appears before an opening brace.

>>> When you use a purely numeric name, it's taken as both the jid
>> I've never hear about this feature. But I'm in doubt how to guarantee jail startup with jid=name=10 along system functioning. If non-numeric jail occupied jid 10 then jail 10  will not start?

> This is not new, jails have operated this way for 15+ years (since 
> numeric names were first allowed).  Indeed, if it's already occupied 
> then the jail already exists and it will not start.

>> However, thinking of jid uniqueness in a wider area than localhost definitely leads us to use a bigger numbers. In such a case using hexadecimal format seems to be beneficial. Then there will be some code to interpret numeric names in decimal/hexadecimal format. So there will be some not so small branch of code  for numeric jail name. And, again, to split  this branch from pure string names I suggest to use name quotation to enforce string interpretation.
>>

>>> I think to prevent ambiguity there must be a possibility or requirement to quote jail name to force interpretation as a string.
>>> Using "47777" instead of 47777 doesn't help for now.
>>> 
>
>> What ambiguity are you referring to here?  In context it's pretty 
>> unambiguous, the name is the thing that appears before an opening brace.
 hex does not
> get resolved to base 10, and you end up with a jail that has a hex name
> and a jid allocated in the usual way.  I'm not sure what else you're 
> writing about here, because it's really not that complicated: if it 
> coerces to a number in base 10 it's the jid, otherwise it's the name. 
> Jails without a name use the jid as their name.

> This review will fix the bug I noted in my previous e-mail:
> https://reviews.freebsd.org/D51831

> Thanks,

> Kyle Evans

>> 
>> Friday, August 8, 2025, 8:24:32 PM, you wrote:
>> 
>>> On 8/6/25 09:37, Anthony Pankov wrote:
>>>> Dear freebsd-hackers.
>>>>> It seems there is no sign that numeric only name is prohibited:
>>>>> "
>>>> The jail name.  This is an arbitrary string that identifies a
>>>>                jail (except it may not contain a ďż˝.ďż˝).
>>>> "
>>>>> But
>>>> # head jail-47777.conf
>>>> ...
>>>> 47777 {
>>>>           host.hostname = "${name}";
>>>> ...
>>>>> # jail -c 47777
>>>> jail: 47777: host.hostname: variable "name" not found
>>>>> If I add letter prefix, say w47777, it worked.
>>>>> Because of strange error "variable "name" not found" it seems like a bug. Does it?
>>>>
>>> This is an artifact of how numeric names work.  When you use a purely numeric name, it's taken as both the jid and the name.  jail(8) has some logic up-front that will set one or the other variable based on the name, but it omits the other.
>> 
>>> I have this almost fixed in 15.0, but trying your example I've found a bug in it -- setting the name, we need to use the string_param() of the KP_JID param as the `value`; the current use of KP_JID's cfparam for `p` to add_param() will adopt the name of KP_JID, which is a peculiarity that I wasn't aware of.
>> 
>>> Thanks,
>> 
>>> Kyle Evans
>> 
>> 
>> 




-- 
Best regards,
 Anthony Pankov                          mailto:anthony.pankov@yahoo.com