Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 458124 - Allow PATH overrides in OpenRC
Summary: Allow PATH overrides in OpenRC
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-18 15:23 UTC by Markos Chandras (RETIRED)
Modified: 2024-03-03 22:14 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markos Chandras (RETIRED) gentoo-dev 2013-02-18 15:23:27 UTC
Hi,

I see that openrc sets a default $PATH in /etc/init.d/functions.sh. I presume this is the $PATH that all scripts use unless told otherwise in their /etc/init.d/$foo file. However, I have some init scripts that need additional paths in $PATH and they break because openRC keeps overriding the PATH on every boot. One option would be to edit all the init scripts ( there are ~20 of them ) to export the PATH they want but I'd prefer it if there was an option in rc.conf to add additional paths in $PATH. The rc_env_allow variable does not seem to do what I want. What I currently do is to edit /etc/init.d/functions.sh and export a new PATH after the default one.
Comment 1 SpanKY gentoo-dev 2013-02-18 19:17:53 UTC
we already have a flexible system for extending the PATH via env.d.  if openrc isn't utilizing that, then maybe we should be fixing that.
Comment 2 Markos Chandras (RETIRED) gentoo-dev 2013-02-18 19:19:48 UTC
(In reply to comment #1)
> we already have a flexible system for extending the PATH via env.d.  if
> openrc isn't utilizing that, then maybe we should be fixing that.

Yes, it does not seem to use it because functions.sh seem to not take into account the existing path but sets a sane minimal one instead.
Comment 3 William Hubbs gentoo-dev 2013-02-18 19:59:37 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > we already have a flexible system for extending the PATH via env.d.  if
> > openrc isn't utilizing that, then maybe we should be fixing that.
> 
> Yes, it does not seem to use it because functions.sh seem to not take into
> account the existing path but sets a sane minimal one instead.

I verified that OpenRC does in fact set variables from profile.env, so we are supporting that. However, it is also correct that functions.sh overwrites the PATH setting.
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2013-02-18 20:12:01 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > we already have a flexible system for extending the PATH via env.d.  if
> > > openrc isn't utilizing that, then maybe we should be fixing that.
> > 
> > Yes, it does not seem to use it because functions.sh seem to not take into
> > account the existing path but sets a sane minimal one instead.
> 
> I verified that OpenRC does in fact set variables from profile.env, so we
> are supporting that. However, it is also correct that functions.sh
> overwrites the PATH setting.

So does source /etc/profile && env-update run before openrc executes any init script? Because in that case, you could fix functions.sh to append the $PATH constructed by the env.d files and job is done. So even if someone has really messed with his env.d files, the default paths will still appear first in the $PATH variable
Comment 5 William Hubbs gentoo-dev 2013-02-21 21:11:45 UTC
(In reply to comment #4)
> > 
> > I verified that OpenRC does in fact set variables from profile.env, so we
> > are supporting that. However, it is also correct that functions.sh
> > overwrites the PATH setting.
> 
> So does source /etc/profile && env-update run before openrc executes any
> init script? Because in that case, you could fix functions.sh to append the
> $PATH constructed by the env.d files and job is done. So even if someone has
> really messed with his env.d files, the default paths will still appear
> first in the $PATH variable

The runscript binary, which is the wrapper for all init scripts, reads /etc/profile.env directly and puts the environment variables from it into the environment. The thing I do not know yet is why functions.sh overwrites the PATH setting a second time.
Comment 6 SpanKY gentoo-dev 2013-03-11 16:07:40 UTC
(In reply to comment #0)

i'm not sure you're reading the code exactly right.  functions.sh doesn't clobber existing PATH ... it only prepends it.  so if you're losing $PATH settings, it's most likely due to other reasons.  like openrc cleansing $PATH, or we aren't running login shells (which source /etc/profile and such).  this latter behavior is to be expected (login vs rc shells), and has a long bug open on the topic.
Comment 7 William Hubbs gentoo-dev 2013-03-14 19:59:25 UTC
I verified that OpenRC reads all environment variables in
/etc/profile.env for each script it runs.
I suggest checking your /etc/profile.env and making sure PATH is set
correctly there.

Once you do this, please re-open this bug if you have more issues. If
you do not have issues, please report back to the bug as well.

Thanks,

William
Comment 8 Markos Chandras (RETIRED) gentoo-dev 2013-05-31 13:40:01 UTC
You are right. openrc reads /etc/profile.env. I probably forgot to run env-update before I reboot that box. Apologies for the noise.
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2013-05-31 14:02:46 UTC
Actually not.

This is the path in my /etc/profile.env

export PATH='/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3:/home/hwoarang/toolchain/mips-2012.09/bin

I've modified the /etc/init.d/functions.sh like this

echo "PATH: ${PATH}"
_path="$(_sanitize_path "$PATH")"
echo "New PATH: ${PATH}"

And this is what I am seeing during boot

PATH: /lib64/rc/bin:/bin:/sbin:/usr/bin:/usr/sbin
New PATH: /lib64/rc/bin:/bin:/sbin:/usr/bin:/usr/sbin
 * Starting vixie-cron ...

So the PATH in /etc/profile.env is not respected. the functions.sh script seems to run with the wrong PATH

Do I miss something?
Comment 10 William Hubbs gentoo-dev 2013-05-31 20:53:15 UTC
Investigating further, I found that the runscript binary, not functions.sh, is where the default path gets initialized.

The env_filter function reads profile.env, if it exists. Environment settings from this file which are not in the environment are added. However, settings which already exist are not changed.

The env_filter function, which is called next, sets PATH to RC_PATH_PREFIX if PATH doesn't exist in the environment, or prepends it with the paths in RC_PATH_PREFIX which are not already mentioned.
Comment 11 William Hubbs gentoo-dev 2013-05-31 20:58:40 UTC
(In reply to SpanKY from comment #6)
> (In reply to comment #0)
> 
> i'm not sure you're reading the code exactly right.  functions.sh doesn't
> clobber existing PATH ... it only prepends it.  so if you're losing $PATH
> settings, it's most likely due to other reasons.  like openrc cleansing
> $PATH, or we aren't running login shells (which source /etc/profile and
> such).  this latter behavior is to be expected (login vs rc shells), and has
> a long bug open on the topic.

Mike, I think we are back to this. We don't want to overwrite PATH with PATH from profile.env, because that adds many other directories to the path which I don't think we would want to be available to init scripts.

What is the bug number you are referring to?
Comment 12 William Hubbs gentoo-dev 2013-05-31 21:34:57 UTC
I am adding a note to this bug to elaborate a little more on the
request.

Markos is requesting that we add a configure option or something similar
that makes binaries in non-standard paths available to init scripts.
Comment 13 William Hubbs gentoo-dev 2013-05-31 22:07:07 UTC
Markos' specific goal is he is using buildbot, and when it starts a
build, it needs to run mips-linux-gnu-gcc, which exists in
/home/hwoarang/toolchain/bin instead of /usr/bin since he is
cross-compiling.
Comment 14 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-01-29 02:56:34 UTC
William says probably WONTFIX. Any objections?

I feel like we've covered this in another bug before, but I can't think where. CCing kerframil as he might've been involved (sorry if you weren't)!
Comment 15 kfm 2023-01-29 08:47:43 UTC
(In reply to Sam James from comment #14)
> William says probably WONTFIX. Any objections?
> 
> I feel like we've covered this in another bug before, but I can't think
> where. CCing kerframil as he might've been involved (sorry if you weren't)!

You were probably thinking of bug 812869.