jbk: I use the in kernel smb for apple timemachine fwiw. Although I can't remember why I ended up using samba to share music to my sonos speaker. I think I couldn't get guest access without a password working

could have been total user error though

yeah.. i have a nas zone on my smartos box that i use for that and it works pretty well..

papertigers: well, older sonos can only do SMB1 - maybe that was it?

o/

Hey

NCommander: So, I think you have to run this suite via "gmake test"

There is at least one critical bug if you run it directly, which is that THIS_SH doesn't get set in the environment until after it's used the first time

Some of these failures are just because they are using essentially unstable output of programs like od(1)

e.g., for us: "printf '\n' | od -t a" prints "0000000 lf", but apparently GNU od prints "0000000 nl"

how od(d)

:P

There are two pieces of delta that don't otherwise seem to be related to the fact that we don't have some of the less common locales: run-test and run-errors. The run-test thing seems to be a test that's supposed to fail, the "enable sh bash" line

It seems like it happens wth an error message structure it was not necessarily expecting

err rather I guess that's the run-errors thing

I'm not sure about the run-test thing, but it's a bit odd. It seems like the test expects that "exec 6>&-" will create file descriptor 6, and it wll apparently be a pipe

but ... I don't see that fd open on the process after using that syntax

Some more digging there required probably

NCommander: I don't see any evidence of bash crashing though, FWIW

(this is OmniOS r151046ac)

oh I was trying to figure out what tab this was coming from

jclulow: that might be environment specific

Give me a moment, I forgot I had this open in the background

ok

bash manpage: "the redirection operator

[n]>&digit-

moves the file descriptor digit to file descriptor n, or the standard

output (file descriptor 1) if n is not specified.

"

I shut down the VM to export it, so I have to boot everything back up

so it's some sort of fd juggle

Ah, gmake check does work

And you're right, no core file. I saw the error about the struct issue. Too used to linux just posting something like that and not coring

I have a core dump of bash dying on login. I also have a few litering around.

FWIW, it's the "enable" built-in using dlsym() to look into itself to find "bash_struct" (to do the "enable bash" thing) and not finding it. It is _expected_ that it doesn't find it, seemingly; I'm not sure what Linux systems do there. It's totally possible the Mac OS X equivalent doesn't use dlsym() but something else.

Given they're Mach-O instead of ELF

So that error pops out there because they print it, in the code in "builtins/enable.def"

I think this test suite is actually in pretty good shape FWIW

gist.github.com/NCommander/ad6684898f400c2611bfb19dc3a7470e - yeah its less broken with gmake

If you run it with the GNU stuff in PATH first, it finds the GNU od and stops whinging about that stuff; e.g., PATH=/usr/gnu/bin:$PATH gmake test

I legitimately forgot about that

The locale stuff is probably because that locale is missing

Well on Mastodon, the locale got brought up as a suspected cause

I just noted they're not installed, since perl was complaining about it when I was trying to build arm64-gate

Yeah I made that suggestion wrt. the segfault/core file stuff

I am uploading the VHDs to Google right now, but they're 72 GiB

So its taking awhile

But because you're ostensibly using en_US.UTF-8 and a stock install, I am less sure it's locale related haha

I've crawled around in bash's internals before

It is not my favourite neighbourhood

(I dunno if you've seen my YouTube channel, I had an adventure with it on AIX)

I have not!

the long story short: old AIX defines strtoimax, but doesn't include it in the headers. It's also buggy

This does *really fun things*, cause a configure check in bash was broken and uh

well needless to say I filed a few bugs on the matter :)

neat

bugs filed is always good haha

Yeah, this is actually me following up on trying to build illumos for arm64, which is largely how I got here.

The stack traceback to me tells me its dying somewhere in readline

Bash has its own built in version that it uses if the system one isn't present, but I think its linked to readline

presumably "ldd /usr/bin/bash" includes /usr/lib/64/libreadline.so.8 in there

        libreadline.so.8 => /usr/lib/64/libreadline.so.8

yeah

We have ourselves a winner

Readline doesn't have a test suite :/

If you "pargs -e <corefile>" can you gist the result

Although there are some compiler warnings

ok

LC_CTYPE=UTF-8 is probably the issue

ncmdr@rosetta2:~/bash-5.2.21$ cat configure.log | grep -i nls

checking whether NLS is requested... yes

checking whether to use NLS... yes

The crash is in readline though

Hold on, let me make a new account which has bash as its shell

so I can test different scenarios

OK I can reproduce it

with... LC_CTYPE=UTF-8 /usr/bin/bash

It is somewhat unconscionable that it handles SIGSEGV haha

ncmdr@rosetta2:~/bash-5.2.21$ LC_CTYPE=UTF-8 /usr/bin/bash -c 'echo HERE'

UTF-8: unknown locale

HERE

ncmdr@rosetta2:~/bash-5.2.21$

It's not crashing here

you're not doing the same thing I was doing

It also does not crash if I pass it a -c argument

with no arguments, it attempts to start an interactive shell

which is when readline comes in

that also worked

I tried that first

Well I can't reproduce the SSH login crash now. I don't think I saved a snapshot before upgrading

what do you get if you: pkg info readline | grep FMRI

on bloody?

er

sorry

ncmdr@rosetta2:~$ pkg info readline | grep FMRI

             FMRI: pkg://omnios/library/readline⊙8:20240402T110232Z

ok and that's ... bloody or stable or?

bloody

ncmdr@rosetta2:~$ uname -a

SunOS rosetta2 5.11 omnios-master-b797611cbb i86pc i386 i86pc

ncmdr@rosetta2:~$

ok tah

The core file for me was generated by selecting /usr/bin/bash as the shell on the OmniOS installer

I could log in ont he system console, but it dumped when I logged into SSH until I changed it to ksh93

this is the stack at the point of the actual SIGSEGV

It has, I believe, passed NULL to strlen()

from _rl_init_eightbit()

I'm going through the code

to see if I can figure out where it blows its brains out

it is in _rl_init_locale()

it is explicitly looking at LC_CTYPE haha

well there's a big giant #if here that relates to a configure check

(looking at readline-8.2 source code)

I believe the #if is true

it is

because "_rl_init_locale::dis ! grep call" in the debugger lists some <PLT=libc.so.1`setlocale> calls

I...

Well, this is where it jumps into the C library

am not sure you are allowed to pass NULL to setlocale() like that?!

oh I guess maybe you are

Well in the case on Linux where locales won't be installed, I think it would go down that codebranch.

It could be a regression in libreadline ...

I'm looking at it in git

This function hasn't changed in like 10 years.

ok so we get "UTF-8" back from the environment lookup

so we are in fact passing it straight to setlocale()

This sounds like the C library is choking

Wasn't NLS one of the bits that was closed source from Sun and had to be replaced?

The i18n stuff

was

ls

this is not my terminal

accurate

I'm trying to find where the other side of that function call goes

yes I am single stepping through

ok so newlocale() in there returns NULL ultimately

because we parsed it rubbish

*passed

we are back in _rl_init_locale()

yeah it passes NULL to strlen() itself

It's in savestring()

in readline-8.2

It seems to have been inlined (blah)

but at the point where it calls strlen() it is about to pass the result to xmalloc()

which is what their savestring() does

So is the bug that readline passes in NULL or illumos's libc not being happy with that NULL? Cause this all looks like old code

The bug is that in the event that a rubbish locale is passed to setlocale(), setlocale() returns NULL because, well, it failed to set the locale

and then

readline does the wrong thing

wait

by assuming it won't be NULL

the manpage actually defines behavior for nullpointer

       A null pointer for locale causes setlocale() to return a pointer to the

       string associated with the category for the program's current locale.

We're not passing in NULL, we're _returning_ NULL

       The program's locale is not changed.

Oh

we pass in what you set in your environment for LC_CTYPE

i.e., "UTF-8"

which is not a locale

oh hold on

I think I see what happens on Linux

"LC_CTYPE=mr_stephens bash" also fails FWIW

I think on Linux, this would return 'C'

I suspect it depends on your C library, but that may well be true

at least some linux manpage suggests it could return NULL as well

mcasadevall@lighthouse:~$ ./test_setlocale

setlocale returned: C

  printf("setlocale returned: %s\n", setlocale(LC_CTYPE, NULL));

It can definitely return NULL

well to be clear

setlocale(LC_CTYPE, "mrstephens")

not NULLL

macOS also returns 'C'

linux actually returns NULL

?

if all you call is setlocale(LC_CTYPE, "mr_stephens");

at least that's true on Ubuntu 22.04.3 LTS

so glibc, really, rather than Linux

yeah my test case was wrong, sorryh, its late here

I believe Mac OS X also returns NULL there

It does seem like /bin/bash on Ubuntu, at least, does _not_ link against libreadline

at least not dynamically

maybe the internal readline is less ruinous

It's likely using the built in one, bash can be set to /bin/sh

And there are some special considerations for /bin/sh and dpkg

sure

So I guess that's why it's not broken there haha

It's also possible that no one has actually run glibc with an entirely invalid lang environment. That code is pretty much older than dirt.

I can't really see how this would not segfault in the same way if you built it linked against the real libreadline -- unless of course they've patched _that_ in Ubuntu

like if you don't have the environmental variables sent

Do you know how LC_CTYPE is getting into your environment?

it sends NULL into setlocale()

As in my SSH shell or on illumos?

on your illumos system yeah

declare -x LANG="en_US.UTF-8"

I am not sure if its getting that from ssh or not

Hold on, let me check locale if I log on the system terminal

we're specifically looking for, like, env | grep LC_CTYPE

Its not set, but its also not crashing now ...

wait

hold on

LC_CTYPE=UTF-8

j'accuse!

I was using cool-retro-term because I was making a video

ah ha

The standard macOS Terminal.app doesn't cause it

but I wanted the fancy graphics

fascinating

I wonder why it does that!

mcasadevall@infinityway ~ % ssh ncmdr⊙110

(ncmdr⊙110) Password:

Last login: Thu Apr 4 05:46:02 2024 from 192.168.2.215

OmniOS r151049 omnios-master-b797611cbb April 2024

You have new mail.

Connection to 192.168.0.102 closed.

mcasadevall@infinityway ~ %

And that infact reproduces the crash

I just checked for good measure and I can ssh into Linux VMs just fine

so uh

You should definitely fix the LC_CTYPE value that cool-retro-term is setting there, I don't believe that's ever valid

I didn't even notice it was broken

cause this was the first time I saw it go kaboom

Well most software probably correctly handles a return of NULL from setlocale() haha

except its a valid locale

C.UTF_8

I believe that would match through locale rules

LC_CTYPE=UTF-8 locale on Ubuntu complains loudly

hold on

I need to figure out what's doing

my locale when logging into Ubuntu over SSH is being set to C.UTF-8

Instead of what its coming in on SSH

so if I login over SSH with an invalid locale, it gets set to C.UTF-8

If I log in with an invalid locale to OmniOS

LC_CTYPE=abcdefg

good lord, /etc/profile.d/01-locale-fix.sh

Yeah ok so they've invented some training wheels in /usr/bin/locale-check haha

if you.. LC_CTYPE=frank /usr/bin/locale-check C.UTF-8

it emits LANG=C.UTF-8 LC_CTYPE=C.UTF-8

Why do I feel like this bug was found a decade ago and this was the fix?

I mean, it is on some level true that not having your locale set properly is bad

but it is also true that it should probably _tell you_

because how would you ever know that your terminal is setting it to something that is totally bogus

cool-retro-term should be passing C.UTF-8 there if that's what wants

or tbh not changing it at all?

I'm pretty sure we are all intended to be coding on VT100's in a dark room ;)

haha

I do recall using Cathode.app a million years ago, before I gave up on the Mac

So the question is what is the actual and proper fix?

I guess patching readline to be less stupid and hope upstream takes it

Yes I believe it is a readline bug

TritonDataCenter/node-manta #61#issuecomment-19653740 is the only evidence I can recall of my Cathode.app use lol

It's possible we could consider sanitising user locale stuff too, though that really feels like a perilous ptah

*path

I'm sure we'll break _other_ things doing stuff like that

Well, hold on, would you? Applications should be expected not to crash if there's a valid locale, and making sure the environment has a safeguard incase of bad terminals is not necessarily a bad thing

It's just a big hammer

Essentially, this is more making getty (or whatever the equivelent is) basically sanity check what comes in, and screech loudly if it dislikes it.

Well, getty/ssh don't care

most programs correctly handle rubbish in the locale variables FWIW

it's why you got all those messages about it haha

It was in fact crying out in pain

I got desensitized to it because debootstrapped Ubuntu doesn't install locales so Perl screaming is normal.

>.>;

I am surprised that this "locale-check" program doesn't warn people about it

I didn't even know it existed

Me neither!

It of course has no manual page despite being in /usr/bin

hold on, I can find who owns it

mcasadevall@lighthouse:~$ dpkg-query -S /etc/profile.d/01-locale-fix.sh

base-files: /etc/profile.d/01-locale-fix.sh

lol, "locale-check --help" silently exits 0

is "base-files" the package?

"I'm not a big fan of this approach but I certainly don't have any better idea myself."

Well they were having postgres explode

... which uses libreadline

Well I found the common thread here :P

lol

indeed

So I can actually provide some context

because I worked on MaaS, albiet loosely

They were basically deploying absolutely minimium images without locales for bare metal VM hosting

This is a deeply magical behavior

it truly is

That's what I mean by peril haha

Like, people will set their locales like your terminal did

and never know they were not getting what they asked for

and stuff will just magically work except sometimes when it doesn't

It really feels like this thing should emit a WARNING to stderr

Arguably, OpenSSH should be sanitizing what its setting the environemnt to

Because its entirely valid that you will have a locale on system A that doesn't exist on system B

Well I believe SunSSH used to actually do thta

*thta

sigh *that

And that formatting doesn't necessarily need to be the same across operating systems

it would negotiate the locale

but we dropped SunSSH (a fork of OpenSSH) long ago

and the OpenSSH people are not into complex stuff like that

yeah I'm not surprised

The ubuntu-devel discussion seems to conclude that openssh is doing the wrong thing

We have our OpenSSH built to AcceptEnv the LC_* LANG stuff by default, as is the broad custom

and then it's just up to users to hold it properly basically

The question becomes is it realistic that OpenSSH will get a locale that's valid on linux/mac/windows, but not valid on illumos, and what the correct behjavior is in that case

It's unfortunately not really possible to say

If you don't follow the spec, and you don't specify a locale that works on the remote system, the best anyone can really do is guess

maybe C, maybe C.UTF-8 if we thought you wanted UTF-8

also what if you specify a correct LANG but a bung LC_COLLATE

It is ultimately a mess haha

Is there an actual defined spec for locales?

I feel like some of it is covered in the various standards yes

between C and POSIX

e.g., pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html

which of course doesn't cover UTF-8 haha

I think C.UTF-8 is actually probably a made up debian thing

that we've mostly all subsequently adopted

The category body shall consist of one or more lines of text. Each line shall contain an identifier, optionally followed by one or more operands. Identifiers shall be either keywords, identifying a particular locale element, or collating elements. In addition to the keywords defined in this volume of POSIX.1-2017, the source can contain

implementation-defined keywords

→ BUG 11661: provide C.UTF-8 locale (Closed)

So there's no defined format

for locale names

Or well, there's nothing saying I can't make my own locale of LANG="pirate_ARGGGG", and be against spec

and then ssh into a normal illumos system from my pirate speaking wonderland

I think that's basically true haha

But I'm not an expert in this area

Neither am I

At any rate, I will file an OmniOS bug describing the readline bug

And we can figure out what to do next

This is getting fairly close the eldritch tomes of lore that AT&T used to forge the One Ring deep in the heart of Murry Hill

I guess fix the readline bug, and see if upstream accepts it, and then deciding if illumos needs to have a locale wrapper, since readline is probably one of the most deployed codebases on the planet

make sure to shoot me the link to that bug, since I'll weigh in. If nothing else, making a video on describing how a bug in libreadline was found will be interesting

I just had a stupid thought

is there any way this can be exploited for code execution? This is a variable a user controls.

I'm not sure it actually gets you anything, but crashing on bad environment data in a library as well used as readline makes me twitchy

no wait, the bad data causes NULL to strlen, nothing a user writes to

ugh, I need sleep

NCommander: omniosorg/omnios-build #3537

I filed the bug

cheers, got a question about NWAM which manages my OI VM's networking: sometimes the home DHCP server from the access point goes AWOL, and the OI VM loses networking (probably lease expires?) -- is it possible to tell it to use the last served address indefinitely until told otherwise? Or a specific fallback IP?

if LAn have multiple gateways, how to tell illumos to always use first gateway (and DNS server) and then if it fails the other one(s).

I see it alternating between gateways to access outside world, even if explicitly set what gateway and DNS to use. (SmartOS)

Silly question... *our* ldd(1) doesn't execute the binary at all while trying to find paths, right?

I'm also pretty sure our strings(1) isn't as dangerous as the binutils one used to be...

our ldd most certainly exec's the binary after setting a bunch of environment variables that cause ld.so to dump its guts rather than run the program.

our ldd does check that the ELF interpreter is in a plausible location (in /lib, /usr/lib, or /etc/lib) which reduces but doesn't eliminate the chance of mischief

strings should probably dumps privs.

s/dumps/drop

danmcd: sorry to disappoint you: github.com/illumos/illumos-gate/blo…rc/cmd/sgs/ldd/common/ldd.c#L36-L39

Oh damn...

Well, glad I asked?

[illumos-gate] 16413 Post-barrier Return Stack Buffer (PBRSB) fixes can be detected in HW -- Dan McDonald <danmcd⊙mi>