New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime path not available after su. #3916

Closed
Vintodrimmer opened this Issue Mar 26, 2017 · 16 comments

Comments

Projects
None yet
4 participants
@Vintodrimmer

Vintodrimmer commented Mar 26, 2017

Good day.

If I run fish in the terminal from the regular user and then execute su root and fish, I get the following errors:

<E> fish: Runtime path not available.
<E> fish: Try deleting the directory /tmp/fish.eichhorn and restarting fish.

Deleting the aforementioned directory removes the error, but I get following error when I try to launcd fish from the regular user:

<E> fish: Runtime path not available.
<E> fish: Try deleting the directory /tmp/fish.eichhorn and restarting fish.
<E> fish: Unable to open a pipe for universal variables using '.notifier': Permission denied

Information about the system:

# fish --version
fish, version 2.5.0
# echo $version
2.5.0
uname -a
Linux chrysalis 4.10.5-chrysalis #1 SMP PREEMPT Fri Mar 24 13:34:49 UTC 2017 x86_64 GNU/Linux
echo $TERM
rxvt-unicode-256color

Distribution is Void Linux.

I've tried to execute sh -c 'env HOME=$(mktemp -d) fish' from user and then switch to root, but the problem persisted

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Mar 26, 2017

Contributor

What is printed if you echo $USER $XDG_RUNTIME_DIR as yourself and after su root?

Contributor

krader1961 commented Mar 26, 2017

What is printed if you echo $USER $XDG_RUNTIME_DIR as yourself and after su root?

@Vintodrimmer

This comment has been minimized.

Show comment
Hide comment
@Vintodrimmer

Vintodrimmer Mar 27, 2017

echo $USER $XDG_RUNTIME_DIR
eichhorn
su root
fish
echo $USER $XDG_RUNTIME_DIR
root

Vintodrimmer commented Mar 27, 2017

echo $USER $XDG_RUNTIME_DIR
eichhorn
su root
fish
echo $USER $XDG_RUNTIME_DIR
root

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Mar 28, 2017

Contributor

When you ran the commands I asked you to run, @Vintodrimmer, did you or did you not get the "Runtime path not available" error when you ran fish after su root? Because a) I can't reproduce your problem and b) fish should have created a /tmp/fish.root directory given that $USER was "root" so there should not have been any conflict. What does ls -ld /tmp/fish.* output? What about ls -l /tmp/fish.*?

Contributor

krader1961 commented Mar 28, 2017

When you ran the commands I asked you to run, @Vintodrimmer, did you or did you not get the "Runtime path not available" error when you ran fish after su root? Because a) I can't reproduce your problem and b) fish should have created a /tmp/fish.root directory given that $USER was "root" so there should not have been any conflict. What does ls -ld /tmp/fish.* output? What about ls -l /tmp/fish.*?

@Vintodrimmer

This comment has been minimized.

Show comment
Hide comment
@Vintodrimmer

Vintodrimmer Mar 28, 2017

Good day, once again.

I did get an error
here's a picture

I should clarify, however, that I also get this issue.

So I added export USER=root to my root's ~/.config/fish/config.fish.

May that cause the problem?

The only folder that is created in the /tmp is for eichhorn.

ls -ld /tmp/fish.*
drwx------ 2 eichhorn eichhorn 60 Mar 28 18:25 /tmp/fish.eichhorn/
ls -l /tmp/fish.*
total 0
prw------- 1 eichhorn eichhorn 0 Mar 28 18:25 fishd.chrysalis.notifier|

Vintodrimmer commented Mar 28, 2017

Good day, once again.

I did get an error
here's a picture

I should clarify, however, that I also get this issue.

So I added export USER=root to my root's ~/.config/fish/config.fish.

May that cause the problem?

The only folder that is created in the /tmp is for eichhorn.

ls -ld /tmp/fish.*
drwx------ 2 eichhorn eichhorn 60 Mar 28 18:25 /tmp/fish.eichhorn/
ls -l /tmp/fish.*
total 0
prw------- 1 eichhorn eichhorn 0 Mar 28 18:25 fishd.chrysalis.notifier|
@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Mar 28, 2017

Member

So I added export USER=root to my root's ~/.config/fish/config.fish.

May that cause the problem?

No, but it will mask it.

@krader1961: Isn't using geteuid(3) the correct thing to do here instead of getuid(3)?

Member

faho commented Mar 28, 2017

So I added export USER=root to my root's ~/.config/fish/config.fish.

May that cause the problem?

No, but it will mask it.

@krader1961: Isn't using geteuid(3) the correct thing to do here instead of getuid(3)?

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Mar 28, 2017

Contributor

Never, ever, explicitly set USER except for testing purposes. If you don't set it is it eichorn after su root? After you su root what does id -ru output? If it isn't zero your su command is broken and that's why you're having this problem.

Contributor

krader1961 commented Mar 28, 2017

Never, ever, explicitly set USER except for testing purposes. If you don't set it is it eichorn after su root? After you su root what does id -ru output? If it isn't zero your su command is broken and that's why you're having this problem.

@Vintodrimmer

This comment has been minimized.

Show comment
Hide comment
@Vintodrimmer

Vintodrimmer Mar 29, 2017

Sorry, for a bit of derailing, but what is a correct way to make fish aware, that I'm now running from root? If I don't set it explicitly, the only difference is the style of the promt.

Here's the output of the comands:
commands

id -ru returns zero.

May it be, becaurse I lack some package? I run a pretty bare-bones installation and may be missing some dependency that is responsible for the actions after su.

Vintodrimmer commented Mar 29, 2017

Sorry, for a bit of derailing, but what is a correct way to make fish aware, that I'm now running from root? If I don't set it explicitly, the only difference is the style of the promt.

Here's the output of the comands:
commands

id -ru returns zero.

May it be, becaurse I lack some package? I run a pretty bare-bones installation and may be missing some dependency that is responsible for the actions after su.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Mar 29, 2017

Member

May it be, becaurse I lack some package? I run a pretty bare-bones installation and may be missing some dependency that is responsible for the actions after su.

No. No dependency is needed here, the issue is much simpler:

  • su changes the user and starts a new fish

  • It leaves the $USER intact, meaning fish simply inherits it

  • Fish assumes the $USER value it has been given is correct (which it usually is)

Now, this can be fixed via simply always setting $USER, but I'm not sure if there isn't some sort of problem with that e.g. in networked setups (where querying the user database for the name takes a network round-trip). We could just use the UID for the filename, but then we'd still have $USER for prompts and such. Also, $HOME could possibly need similar treatment - my su sets it properly (and it also sets $USER, unless you are switching to root 😠), but maybe others don't.

Member

faho commented Mar 29, 2017

May it be, becaurse I lack some package? I run a pretty bare-bones installation and may be missing some dependency that is responsible for the actions after su.

No. No dependency is needed here, the issue is much simpler:

  • su changes the user and starts a new fish

  • It leaves the $USER intact, meaning fish simply inherits it

  • Fish assumes the $USER value it has been given is correct (which it usually is)

Now, this can be fixed via simply always setting $USER, but I'm not sure if there isn't some sort of problem with that e.g. in networked setups (where querying the user database for the name takes a network round-trip). We could just use the UID for the filename, but then we'd still have $USER for prompts and such. Also, $HOME could possibly need similar treatment - my su sets it properly (and it also sets $USER, unless you are switching to root 😠), but maybe others don't.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Mar 29, 2017

Contributor

Some su commands leave $USER unchanged only when switching to the root account and only if you don't use the -l flag. And some always set it to the id being switched to even if that user is root. $HOME is also unchanged unless you do su -l. In short you really should always use su -l. 😄 In fact, what I recommend is sudo su -l so you only need your password, not the root password.

We've been asked about this behavior at least twice that I could find: #2745 and #1828. And I'm pretty sure I've seen the same question on IRC/Gitter. We can certainly modify fish to display a warning and then "fix" the HOME and USER vars. Whether we should do so depends on whether anyone can think of how that could cause a different set of problems. Obviously we'll probably only want to do this for the root user since a) that's the only case where people are experiencing problems and b) if we always did it then the sh -c 'env HOME=$(mktemp -d) fish' trick wouldn't work.

Contributor

krader1961 commented Mar 29, 2017

Some su commands leave $USER unchanged only when switching to the root account and only if you don't use the -l flag. And some always set it to the id being switched to even if that user is root. $HOME is also unchanged unless you do su -l. In short you really should always use su -l. 😄 In fact, what I recommend is sudo su -l so you only need your password, not the root password.

We've been asked about this behavior at least twice that I could find: #2745 and #1828. And I'm pretty sure I've seen the same question on IRC/Gitter. We can certainly modify fish to display a warning and then "fix" the HOME and USER vars. Whether we should do so depends on whether anyone can think of how that could cause a different set of problems. Obviously we'll probably only want to do this for the root user since a) that's the only case where people are experiencing problems and b) if we always did it then the sh -c 'env HOME=$(mktemp -d) fish' trick wouldn't work.

@Vintodrimmer

This comment has been minimized.

Show comment
Hide comment
@Vintodrimmer

Vintodrimmer Mar 30, 2017

In short you really should always use su -l

And that completely solves the problem. Thank you very much!

Vintodrimmer commented Mar 30, 2017

In short you really should always use su -l

And that completely solves the problem. Thank you very much!

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Apr 7, 2017

Member

You know, that failure mode is unacceptable, I'm reopening this.

Member

faho commented Apr 7, 2017

You know, that failure mode is unacceptable, I'm reopening this.

@faho faho reopened this Apr 7, 2017

@faho faho added enhancement and removed question labels Apr 7, 2017

faho added a commit to faho/fish-shell that referenced this issue Apr 7, 2017

Force setting $USER and $HOME if UID is 0
Works around some weird su implementations.

Fixes fish-shell#3916.
@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Apr 7, 2017

Contributor

I agree, @faho. I would have reopened it myself but didn't notice that it was closed. We should definitely be friendlier than other shells in the face of this su bogosity. So the question is whether my proposal in my previous comment is the right fix or should we do something else.

Contributor

krader1961 commented Apr 7, 2017

I agree, @faho. I would have reopened it myself but didn't notice that it was closed. We should definitely be friendlier than other shells in the face of this su bogosity. So the question is whether my proposal in my previous comment is the right fix or should we do something else.

@krader1961 krader1961 added this to the fish-future milestone Apr 7, 2017

@krader1961 krader1961 added the RFC label Apr 7, 2017

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Apr 7, 2017

Member

@krader1961: Check out faho@ec39b49, which is my attempt.

What it does is just always set $USER and $HOME if uid == 0, otherwise it keeps trusting the inherited values. The idea behind it was that this was the only case we actually practically encountered.

I don't think this warrants a warning or error - the only thing that would do would annoy people who use su. They're not gonna stop, su isn't gonna change. What happens when an unstoppable force meets a small object (say, a fish)? Yeah, right.

Of course more elaborate solutions are also possible:

  • We could introduce a $UID variable, like bash has - here $USER would stay at the old value while $UID would be 0. Note that some BSDs apparently have 2 users with uid 0 ("root" and "toor"), so having the uid might be helpful. OTOH we're not going to stop people from using $USER.

  • We could use the uid as much as possible (for finding the tmp file, for getting $HOME) and just punt on the issue of telling the user "you are root" entirely - have them use id.

  • We could force getting $USER more often - as I said above, I'm not sure how that interacts with more elaborate environments than my humble home, with ldap and kerberos and whatnot. I'm under the impression that in these cases getuid will be a local call, while getpw and friends might go over the network, which is slow.

  • Combinations of these are also possible - introduce $UID, get $USER if uid == 0 and rely on $USER less.

Member

faho commented Apr 7, 2017

@krader1961: Check out faho@ec39b49, which is my attempt.

What it does is just always set $USER and $HOME if uid == 0, otherwise it keeps trusting the inherited values. The idea behind it was that this was the only case we actually practically encountered.

I don't think this warrants a warning or error - the only thing that would do would annoy people who use su. They're not gonna stop, su isn't gonna change. What happens when an unstoppable force meets a small object (say, a fish)? Yeah, right.

Of course more elaborate solutions are also possible:

  • We could introduce a $UID variable, like bash has - here $USER would stay at the old value while $UID would be 0. Note that some BSDs apparently have 2 users with uid 0 ("root" and "toor"), so having the uid might be helpful. OTOH we're not going to stop people from using $USER.

  • We could use the uid as much as possible (for finding the tmp file, for getting $HOME) and just punt on the issue of telling the user "you are root" entirely - have them use id.

  • We could force getting $USER more often - as I said above, I'm not sure how that interacts with more elaborate environments than my humble home, with ldap and kerberos and whatnot. I'm under the impression that in these cases getuid will be a local call, while getpw and friends might go over the network, which is slow.

  • Combinations of these are also possible - introduce $UID, get $USER if uid == 0 and rely on $USER less.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Apr 7, 2017

Contributor

My thought behind issuing a warning is that it would also encourage the user to use su -l to avoid the warning. But you're probably right that it will just annoy people rather than get them to change their habits.

I'd prefer your simple solution assuming no one can see how that would cause problems And I can't see how it would other than possibly in some only vaguely UNIX like OS (e.g., Haiku). And if that happens we can always special-case that environment.

Contributor

krader1961 commented Apr 7, 2017

My thought behind issuing a warning is that it would also encourage the user to use su -l to avoid the warning. But you're probably right that it will just annoy people rather than get them to change their habits.

I'd prefer your simple solution assuming no one can see how that would cause problems And I can't see how it would other than possibly in some only vaguely UNIX like OS (e.g., Haiku). And if that happens we can always special-case that environment.

@krader1961 krader1961 removed the RFC label Apr 7, 2017

faho added a commit to faho/fish-shell that referenced this issue Apr 7, 2017

Force setting $USER and $HOME if UID is 0
Works around some weird su implementations.

Fixes fish-shell#3916.

@faho faho referenced this issue Apr 7, 2017

Closed

Workaround su #3944

0 of 1 task complete
@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Apr 9, 2017

Member

I'm not convinced that exchanging a modifiable behaviour for an unmodifiable one is the right thing to do here.

Member

zanchey commented Apr 9, 2017

I'm not convinced that exchanging a modifiable behaviour for an unmodifiable one is the right thing to do here.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Apr 9, 2017

Member

Okay, so how about this then:

  • We check if the uid for $USER is equal to getuid()

  • If it is, we use $USER and $HOME

  • It is isn't, we get a new $USER and $HOME

That way, you could still use the env HOME trick, but to use it with su you'd need to either also override $USER, or you'd need to use su -l. The common case of just launching su -c fish would work properly (instead of how it is now).

(Note: We could also just use $HOME if $USER == "root" and uid == 0, but that might fail with the "toor" user or similar)

Member

faho commented Apr 9, 2017

Okay, so how about this then:

  • We check if the uid for $USER is equal to getuid()

  • If it is, we use $USER and $HOME

  • It is isn't, we get a new $USER and $HOME

That way, you could still use the env HOME trick, but to use it with su you'd need to either also override $USER, or you'd need to use su -l. The common case of just launching su -c fish would work properly (instead of how it is now).

(Note: We could also just use $HOME if $USER == "root" and uid == 0, but that might fail with the "toor" user or similar)

@faho faho closed this in 3fa5d6c Apr 18, 2017

@faho faho modified the milestones: 2.6.0, fish-future Apr 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment