Re: -fstack-clash-protection triggers something in setfstab()

[+grembo@ for iocage]

On 3/15/25 06:26, Alexander Leidinger wrote:
> Am 2025-02-26 16:20, schrieb Alexander Leidinger:
>> Hi,
>>
>> the working system is from 2025-01-25-141603, the non working system 
>> is from 2025-02-21-115311.
>>
>> I'm not sure what the issue is exactly. I have traced down the change 
>> of behavior to
>> ---snip---
>> if not LIBC.setfstab(fstab_file_path.encode()):
>> ---snip---
>>
>> In the working case LIBC.setfstab returns true (so with the not it 
>> doesn't take this branch), and in the non-working case it returns 
>> false (so with the not it takes this branch).
>>
>> Is someone aware of a change in this area? Searching for it (https:// 
>> cgit.freebsd.org/src/log/?qt=grep&q=setfstab) only brings the initial 
>> commit.
> 
> Interestingly my own commit triggers this issue.
> 
> I bisected and commit 1c2ae9233b0ed4f6b92c59c0e4026f6ddc073e4a is 
> causing this. This is the first ref which triggers the issue that iocage 
> can not mount filesystems anymore. And the failing call in iocage seems 
> to be the python LIBC.setfstab() call. And this only triggers, when the 
> basesystem is compiled with the stack clash protection. I do not see any 
> obvious issue in our setfstab code. Anyone with an idea?
> 
setfstab() implementation seems more or less fine, but it's hard to tell 
what's going on with iocage there.  setfstab(3) doesn't actually have a 
return value in any version of FreeBSD, so I guess it's picking up some 
sort of garbage as the return value.

Looking at the context, you can only tell if the open failed with the 
subsequent getfsent()/setfsent(); that branch should probably just be 
removed entirely, and the initial getfsent() might be worth 
error-checking for potential error or premature EOF.

Thanks,

Kyle Evans