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

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. 

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


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