Don't trust $USER

[buddhi-deep]

fish, version 3.3.1 in chroot

I login with user safety(though it's unsafe at all),why fish shell think im a root user,ash and bash think im not root user

[faho]

Fish thinks you are the root user because your uid is 0. You are root inside the container.

Bash simply trusts the $USER environment variable and reflects that, fish doesn't if the uid is 0.

[buddhi-deep]

But the user safety in container is always 1000,not 0,it was created when init a new container

[buddhi-deep]

When i do su safety,fish think im not root,but if i do chroot --userspec safety:safety,fish think I'm root

[ridiculousfish]

What does whoami and echo $USER print?

[faho]

What happens here is that, at some point, fish runs getuid, and that returns 0, and then it runs getpasswd for that, and it tells it the name belonging to UID 0 is "root".

Even a diverging effective user id ("euid") won't help, because you can always set your effective uid to your real uid (even without special permissions).

I have no real idea what is happening here, and what exactly chroot is changing here. All I know is that fish asks the system which user it is, and the system insists it is root with a UID of 0.

Note that this is also broken inside bash - you can see the chosen $USER in the prompt (if you use the \u PS1 escape), but try to cd ~ and it will try to cd /root!

What does whoami and echo $USER print?

@ridiculousfish In both bash and fish: whoami will print the chosen user, $USER will be set to root.

[faho]

Aaah, okay. I think I know what's happening here. I had the failure mode entirely the wrong way around!

Bash won't actually use $USER, ever, while fish will trust it when the uid isn't 0.

We do getuid(), it says some uid that's not 0, and fish then trusts $USER - because this was introduced to work around sus awkwardness of keeping $USER set. If it did give us 0, we would update $USER from passwd, and probably end up with "root". Ironically, in this case, the uid is not 0, but $USER is "root", so there's still a mismatch.

One possibility here is to update $USER, always, instead of ever trusting it. We want to have $USER be meaningful, because we don't have another way of reading it (like bash's \u expansion in $PS1, which does not use $USER, apparently), and that's what your prompt is reading.

[buddhi-deep]

I solved that
Set user=safety
Now my scriptctcontainer is good to go thx

[faho]

This is not fixed, there is merely a workaround. The issue is that we can still inherit a wrong $USER.

I think the best thing we can do is fix $USER always instead of just when the uid is 0.