https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8415

It's also useful to have the actual error with the backtrace (though I assume it's a segfault).

Did you try the setenv thing?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8416

Oh, another thing to check is that the program isn't setuid.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8417

Also, `cat /proc/[PID]/personality` should print `00200000` if the `personality()` call succeeded.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8421

`setenv` thing, did you mean `setarch`? And yes, I did try that...

The actual backtrace is above, or did you mean something else?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8422

It doesnt appear to be

```
root@419aa74cc0e0:/opt/sbbs# ls -al /opt/sbbs/exec/sbbs
-rwxr-xr-x 1 root root 192928 Jan 20 22:59 /opt/sbbs/exec/sbbs
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8423

I cant do this, as it coredumps almost immediately.

However, if I start it with NO_EVENTs, then:

```
sbbs -t-

[in another window]
root@8e025d59d208:/opt/sbbs# ps -Af
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 18:33 pts/0 00:00:00 bash
root 16 1 0 18:33 pts/0 00:00:00 sbbs -t-
root 25 0 0 18:34 pts/1 00:00:00 bash
root 31 25 0 18:34 pts/1 00:00:00 ps -Af root@8e025d59d208:/opt/sbbs# cat /proc/16/personality
00200000
```

Container is started with `docker run -it --rm --privileged=true local/sbbs bash`
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8428

Hrm, so this is likely an issue with `TASK_UNMAPPED_BASE` possibly due to a large `TASK_SIZE`. Not sure if these can be configured at runtime or if they're set when the kernel is compiled, digging a bit more.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8429

Is the kernel using 64k pages? You can check with `getconf PAGESIZE`. If so, possibly changing to a 4k page kernel will solve the problem.

If not, I can try forcing an mmap() and hope it grows down from there.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8430

Another possible option would be disabling ASLR... simply adding ` | ADDR_NO_RANDOMIZE` to the `personality()` call in `sbbscon.c` should do that.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8431

I've committed a change that adds commented-out code with the two possibilities in sbbscon.c. Can you play with them and see if any of the three by itself is sufficient, or worst case, if a combination of the third (mmap) and one of the first two works?

Order of preference:
1. mmap
2. mmap + personality() leaving ASLR enabled
3. personality() disabling ASLR
4. mmap + personality() disabling ASLR
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8432

Looks like 4K.

```
root@65153ed9ef70:/opt/sbbs# getconf PAGESIZE
4096
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8435

OK, no success:

* Only `personality(ADDR_COMPAT_LAYOUT | PER_LINUX);` (as per checkout), coredump on the same line:
```
#0 0x0000fffc84bcad88 in JSObject::getClass (this=0x7ffc5b404100) at jsobj.h:427
```

* Only `personality(ADDR_COMPAT_LAYOUT | ADDR_NO_RANDOMIZE | PER_LINUX);` coredump on the same line
```
#0 0x0000fffb214a2d88 in JSObject::getClass (this=0x7ffaf7e04100) at jsobj.h:427
```

* Only ` void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);` compile errors:
```
Compiling sbbscon.c
sbbscon.c: In function 'main':
sbbscon.c:1211:25: warning: implicit declaration of function 'mmap' [-Wimplicit-function-declaration]
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~
sbbscon.c:1211:65: error: 'PROT_NONE' undeclared (first use in this function); did you mean 'XLAT_NONE'?
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~
| XLAT_NONE
sbbscon.c:1211:65: note: each undeclared identifier is reported only once for each function it appears in
sbbscon.c:1211:76: error: 'MAP_PRIVATE' undeclared (first use in this function); did you mean 'LP_PRIVATE'?
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~~~
| LP_PRIVATE
sbbscon.c:1211:90: error: 'MAP_ANONYMOUS' undeclared (first use in this function); did you mean 'MSG_ANONYMOUS'?
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~~~~~
| MSG_ANONYMOUS
sbbscon.c:1211:106: error: 'MAP_FIXED_NOREPLACE' undeclared (first use in this function)
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~~~~~~~~~~~~~
sbbscon.c:1211:15: warning: unused variable 'hackPtr' [-Wunused-variable]
1211 | void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);
| ^~~~~~~
make[1]: *** [/opt/sbbs/repo/src/sbbs3/../build/Common.gmake:568: gcc.linux.aarch64.obj.debug-mt/sbbscon.o] Error 1
```

Did I do it right? Each build was run with `make -f install-sbbs.mk DEBUG=1 NO_X=1 SBBSDIR=/opt/sbbs`
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8436

Yeah, you did it right, I fogot to add the include file for mmap. Just pushed a new change with that fix in it, so mmap() should be usable.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8437

OK:

* only `void *hackPtr = mmap((void*)((1UL << 47) - 4096), 4096, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE, -1, 0);` still core dumps
```
#0 0x0000fffb9d509d88 in JSObject::getClass (this=0x7ffb83e04100) at jsobj.h:427
```

* `void ...` + `personality(ADDR_COMPAT_LAYOUT | PER_LINUX);`
```
#0 0x0000fffbe7284d88 in JSObject::getClass (this=0x7ffbd9c04100) at jsobj.h:427
```

* `void ...` + `personality(ADDR_COMPAT_LAYOUT | ADDR_NO_RANDOMIZE | PER_LINUX);`
```
#0 0x0000fffc59921d88 in JSObject::getClass (this=0x7ffc54204100) at jsobj.h:427
```

No cigar ;(
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8439

Ok, so fundamentally what we need to do is to get the used memory locations below `0x00007fffffffffff`.

The nuclear option here is to add ` | ADDR_LIMIT_32BIT` to the `personality()` call, which should limit the Synchronet memory space to around 3GB.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8441

The Google AI us suggesting various things that may or may not work to have the QEMU restrict the address space appropriately. I'm not familiar enough with Proxmox or QEMI aarch64 to evaluate how garbage the suggestions are.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8441

The Google AI is suggesting various things that may or may not work to have the QEMU restrict the address space appropriately. I'm not familiar enough with Proxmox or QEMI aarch64 to evaluate how garbage the suggestions are.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8442

The one that looks most promising is running sbbs using prlimit as `prlimit --as=140737488355327 /path/to/sbbs`. If this works, you can configure the limit for the user in `/etc/security/limits.conf`.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8443

PROT_NONE = pages may not be accessed = segfault
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8444

No cigar here either :disappointed: Tried the `prlimit` and `ADDR_LIMIT_32BIT`...

Going along with the memory thing, I also reduced the VM to 2GIG it didnt help either.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8445

Can you try setting the 32-bit personality using `setarch -B`? It's almost certainly "too late" for it to be attempted in `main()` itself since that address of `main()` will be something like `0x0000fffffffff284` which is already outside of the 32-bit space.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8446

Finally found the [upstream issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1143022). I'll dig into this in the next couple days and see if a reasonable patch can be added.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8447

Just pushed SpiderMonkey patch that may resolve the issue. At the very least, it shouldn't crash anymore, so it should either work or complain that it can't allocate anything.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8448

Yep, hackPtr is never accessed.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8449

Still core dumps on start - but looks like a different backtrace

```
#0 0x0000fff083d955f8 in JSString::isRope (this=0x7ff0841c15b0) at jsstr.h:217 #1 JSString::ensureLinear (this=0x7ff0841c15b0, cx=0xfff0580193e0) at jsstr.h:366
#2 0x0000fff083ecfe5c in ArgToRootedString (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00280, arg=1) at jsstr.cpp:360
#3 0x0000fff083edabc0 in js::str_replace (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00268) at jsstr.cpp:2489
#4 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00268, argc=2, native=0xfff083eda51c <js::str_replace(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#5 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea001b8, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#6 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff05807c150, fp=0xfff05ea001b8) at jsinterp.cpp:653
#7 0x0000fff083e3b3b4 in js::Invoke (cx=0xfff0580193e0, argsRef=..., flags=16384) at jsinterp.cpp:740
#8 0x0000fff083e00f60 in js_fun_apply (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00170) at jsfun.cpp:2205
#9 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00170, argc=2, native=0xfff083e00a2c <js_fun_apply(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#10 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea00118, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#11 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff058090440, fp=0xfff05ea00118) at jsinterp.cpp:653
#12 0x0000fff083e3cde8 in js::Execute (cx=0xfff0580193e0, chain=0x700000031360, script=0xfff058090440, prev=0x0, flags=0, result=0xfff05ffc5148) at jsinterp.cpp:1028
#13 0x0000fff083d91ad0 in JS_ExecuteScript (cx=0xfff0580193e0, obj=0x700000031360, scriptObj=0x700000031708, rval=0xfff05ffc5148) at jsapi.cpp:4998
#14 0x0000fff083c4790c in js_load (cx=0xfff0580193e0, argc=3, arglist=0xfff05ea000a8) at js_global.cpp:707
#15 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea000a8, argc=3, native=0xfff083c45660 <js_load(JSContext*, uintN, jsval*)>, cx=0xfff0580193e0) at jscntxtinlines.h:701
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8449

Still core dumps on start - but looks like a different backtrace

```
#0 0x0000fff083d955f8 in JSString::isRope (this=0x7ff0841c15b0) at jsstr.h:217 #1 JSString::ensureLinear (this=0x7ff0841c15b0, cx=0xfff0580193e0) at jsstr.h:366
#2 0x0000fff083ecfe5c in ArgToRootedString (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00280, arg=1) at jsstr.cpp:360
#3 0x0000fff083edabc0 in js::str_replace (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00268) at jsstr.cpp:2489
#4 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00268, argc=2, native=0xfff083eda51c <js::str_replace(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#5 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea001b8, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#6 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff05807c150, fp=0xfff05ea001b8) at jsinterp.cpp:653
#7 0x0000fff083e3b3b4 in js::Invoke (cx=0xfff0580193e0, argsRef=..., flags=16384) at jsinterp.cpp:740
#8 0x0000fff083e00f60 in js_fun_apply (cx=0xfff0580193e0, argc=2, vp=0xfff05ea00170) at jsfun.cpp:2205
#9 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea00170, argc=2, native=0xfff083e00a2c <js_fun_apply(JSContext*, unsigned int, js::Value*)>, cx=0xfff0580193e0)
at jscntxtinlines.h:701
#10 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea00118, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#11 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff058090440, fp=0xfff05ea00118) at jsinterp.cpp:653
#12 0x0000fff083e3cde8 in js::Execute (cx=0xfff0580193e0, chain=0x700000031360, script=0xfff058090440, prev=0x0, flags=0, result=0xfff05ffc5148) at jsinterp.cpp:1028
#13 0x0000fff083d91ad0 in JS_ExecuteScript (cx=0xfff0580193e0, obj=0x700000031360, scriptObj=0x700000031708, rval=0xfff05ffc5148) at jsapi.cpp:4998
#14 0x0000fff083c4790c in js_load (cx=0xfff0580193e0, argc=3, arglist=0xfff05ea000a8) at js_global.cpp:707
#15 0x0000fff083e2f26c in js::CallJSNative (vp=0xfff05ea000a8, argc=3, native=0xfff083c45660 <js_load(JSContext*, uintN, jsval*)>, cx=0xfff0580193e0) at jscntxtinlines.h:701
#16 js::Interpret (cx=0xfff0580193e0, entryFrame=0xfff05ea00048, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:4799
#17 0x0000fff083e3a8dc in js::RunScript (cx=0xfff0580193e0, script=0xfff05807b4e0, fp=0xfff05ea00048) at jsinterp.cpp:653
#18 0x0000fff083e3cde8 in js::Execute (cx=0xfff0580193e0, chain=0x700000031360, script=0xfff05807b4e0, prev=0x0, flags=0, result=0xfff05ffcb240) at jsinterp.cpp:1028
#19 0x0000fff083d91ad0 in JS_ExecuteScript (cx=0xfff0580193e0, obj=0x700000031360, scriptObj=0x7000000313a8, rval=0xfff05ffcb240) at jsapi.cpp:4998
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x0000fff083bca578 in sbbs_t::js_execfile (this=0xfff074078cc0, cmd=0xfff07408bafa "logonlist -m", startup_dir=0xfff0840b6750 "", scope=0x0, js_cx=0xfff0580193e0,
js_glob=0x700000003048) at exec.cpp:692
#21 0x0000fff083d5fe24 in sbbs_t::external (this=0xfff074078cc0, cmdline=0xfff07408baf9 "?logonlist -m", mode=256, startup_dir=0xfff0840b6750 "") at xtrn.cpp:1169
#22 0x0000fff083cd2740 in sbbs_t::daily_maint (this=0xfff074078cc0) at main.cpp:4891
#23 0x0000fff083cc76f8 in event_thread (arg=0xfff074078cc0) at main.cpp:3107 #24 0x0000fff083902648 in start_thread (arg=0xfff05fffeac0) at pthread_create.c:477
#25 0x0000fff083858c9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8450

Yeah, I have a theory of what's happening here, can you try running this build using `setarch --addr-compat-layout`?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8451

Added a few new commits so you don't need to use `setarch`. :slight_smile:
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8452

Winner :smile:

At first glance, sbbs starts and doesnt segfault. This is a vanilla environment compiled from `master/a90a05372`. I'll compile a clean container, without `DEBUG=1` to do more tests.

I did have to start the container privileged, I dont have the error on hand but from memory it was something like `personality(): permission denied` (and I was root at the time in the container). Would you know off the top of your head what capability it needs, so I dont have to give it privileged?

Appreciate your help in getting this working - thank you.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8453

The error when not running privileged is `personality() failed: Operation not permitted`
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8454

I don't even know what the set of capabilities is or where that's documented. :grinning:

The changes basically:
1. Read the current personality using `personality(0xffffffff)`.
2. Set the new personality using `personality(ADDR_COMPAT_LAYOUT | current_personality)`
3. Re-executes itself using the `/proc/self/exe` symlink.

From the message, it sounds like either 1 or 2 is being blocked. There's a lot of other things `personality()` can potentially do, such as disabling ASLR which something may be blocking the function completely over without inspecting the value.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8455

AI tells me this:

**1. Seccomp Permission**
The default Docker Seccomp Profile returns EPERM (Operation not permitted) for personality() unless it is called with specific, safe flags (like those used for uname emulation). ADDR_COMPAT_LAYOUT is generally not in this "safe" allowlist.
_Recommendation:_ Use --security-opt seccomp=unconfined to verify if this is the only blocker.
_Production Fix:_ Create a Custom Seccomp Profile that adds personality to the syscalls allowlist without restrictions on the arguments.

**2. Capabilities**
While some personality() flags are unprivileged, modifying the memory layout of a process can sometimes be gated by CAP_SYS_ADMIN depending on the specific kernel version and architecture-specific security patches.
_Requirement:_ Add the capability using --cap-add=SYS_ADMIN.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Deon George wrote to GitLab note in main/sbbs <=-

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8453

The error when not running privileged is `personality() failed:
Operation not permitted`

My guess would be that it's trying to bind to a port < 1024.



... Gone crazy, be back later, please leave message.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8457

Dang, I was posting some testing updates, that I must not have submitted.

I did some AI searching too (because this is all foreign to me), and AI told me it was related to ASLR (whatever that is).

I tried `--cap-add=SYS_ADMIN` without success, and even `--security-opt seccomp=unconfined`, which it started then segfaulted again.

```
(gdb) bt
#0 0x0000400001418d6c in cleanup(int, int) [clone .constprop.0] () from /opt/sbbs/exec/libftpsrvr.so
#1 0x000040000141d9d4 in ftp_server () from /opt/sbbs/exec/libftpsrvr.so
#2 0x0000400001526648 in start_thread (arg=0x40000539aac0) at pthread_create.c:477
#3 0x0000400001621c9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```

(This time ftp_server is the second line, a previous start it was mail_server.)

As I worked throught it with AI, it tells me:
```
If --security-opt seccomp=unconfined allows the application to proceed but it immediately segfaults, you have likely moved from a "permissions" problem to a "compatibility" or "memory mapping" problem.

Likely Causes for the Segfault
Architecture Mismatch (Emulation Issues): [NO LIKELY? since its qemu aarch64 on aarch64].

GDB / Debugger Conflicts: If you are using a debugger like GDB, it calls personality(ADDR_NO_RANDOMIZE) to make memory addresses deterministic. If the application's internal memory management expects randomized addresses (or vice-versa), it can crash.

Invalid Memory Access: The application may be attempting to access a memory address that is only valid in a specific "personality" (like a 32-bit address space), but failing to map that memory correctly once the syscall succeeds.
```

I tried the recommended `echo 0 | sudo tee /proc/sys/kernel/randomize_va_space` no change.

Looks like I might be stuck with `privileged` mode :( (But happy it looks like its working.)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8458

So, that segfault does not appear to be Javascript related at all, so is likely a different issue.

All three of those AI suggestions appear to be hogwash.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: sbbs binary: Debian Linux AARCH64 sigfault or permission denied
By: Gamgee to Deon George on Fri Feb 27 2026 08:29 am

Howdy,

The error when not running privileged is `personality() failed: Operation not permitted`

My guess would be that it's trying to bind to a port < 1024.

Nope, its running as root.


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8484

Yeah, sometimes AI is helpful, sometimes its not - fair enough.. :smile:

Do you want a debug backtrace for that segfault - in case it is a different issue?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8486

Apologies... I never followed up after I got my similar issue above working. Hopefully this will help you.

My working container build https://github.com/jagould2012/cyberdeck/blob/main/bbs/Dockerfile

My branch with debug output and stacktrace capture that I used to track the issue down
https://github.com/jagould2012/cyberdeck/blob/feature/bbs-arm64-testing/bbs/Dockerfile.arm64-debug
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8487

Always want a debug backtrace of any segfault, yes please.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/685#note_8488

Here you go:

```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 std::__atomic_base<unsigned int>::load (__m=std::memory_order_seq_cst, this=0x4) at /usr/include/c++/10/bits/atomic_base.h:426
426 /usr/include/c++/10/bits/atomic_base.h: No such file or directory. [Current thread is 1 (Thread 0x400005cc61c0 (LWP 11))]
(gdb) bt
#0 std::__atomic_base<unsigned int>::load (__m=std::memory_order_seq_cst, this=0x4) at /usr/include/c++/10/bits/atomic_base.h:426
#1 std::__atomic_base<unsigned int>::operator unsigned int (this=0x4) at /usr/include/c++/10/bits/atomic_base.h:289
#2 0x00004000015c5f58 in cleanup (code=1) at mailsrvr.cpp:6094
#3 0x00004000015c6e20 in mail_server (arg=0xaaaaaaacd5d8 <mail_startup>) at mailsrvr.cpp:6295
#4 0x0000400001650648 in start_thread (arg=0x400005cc5ac0) at pthread_create.c:477
#5 0x000040000174bc9c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
```

Oh wait, I just discovered the possible reason (but it shouldnt segfault anyway?).

I started my container without initialising the configuration (so no ctrl/ dir) - so it earlier complains about:

```
3/1 21:42:58 term !ERROR loading configuration files: ERROR 2 (No such file or directory) opening /opt/sbbs/ctrl/main.ini
3/1 21:42:58 term Terminal Server thread terminating
3/1 21:42:58 srvc !ERROR loading configuration files: 2 opening /opt/sbbs/ctrl/text.dat
[Threads: 5 Sockets: 0 Clients: 0 Served: 0 Errors: 2] (?=Help): Segmentation fault (core dumped)
```

When I initialised the configuration (which puts in place ctrl it stays running :)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)