Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer,comp.unix.shell
Subject: Re: Default PATH setting - reduce to something more sensible?
Followup-To: comp.unix.shell
Date: Tue, 14 Jan 2025 13:55:19 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vm5qc7$ft9$1@reader2.panix.com>
References: <vm5dei$2c7to$1@dont-email.me>
Injection-Date: Tue, 14 Jan 2025 13:55:19 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="16297"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4896
Lines: 88

[Meta note: This is more of a comp.unix.shell sort of post; not
so much comp.unix.programmer.  Followup-To: set accordingly.]

In article <vm5dei$2c7to$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>When I recently inspected an 'strace' log and saw the huge amount
>of system-calls done for a simple standard command (like 'rm') -
>it's more than a dozen! and most lead just to ENOENT - I wondered
>about the default PATH definition which is for my system
>  /usr/lib/lightdm/lightdm
>  /usr/local/sbin
>  /usr/local/bin
>  /usr/sbin
>  /usr/bin
>  /sbin
>  /bin
>  /usr/games
>(here I'm omitting my own additions, '~/bin' and '.', and I separated
>them, one on each line for a better visualization of the "problem" or,
>maybe better, for the "questions".)

On a single-user system, it's not a huge deal, but on a
multiuser system where you may `cd` into a directory writable by
anyone (such as /tmp), `.` in $PATH is a known security problem.
YMMV, but caveat emptor.

>The above PATH components are for a terminal running under some
>window manager, a plain console window will not show the 'lightdm'
>entry (but I rarely work on plain consoles).
>
>This raises a few questions, and someone may shed some light on the
>rationale for above default settings... (and how to "fix" it best)
>
>Why do I need 'lightdm/lightdm' in the user's PATH variable defined?
>(That directory contains just one special script and one executable.)
>This entry is what annoys me most; it also reminds me of systems that
>have every program vendor add an own PATH entry for their products.
>Would it be safe to just remove that (in my '~/.profile') from PATH?
>Or can I make it vanish by some other change, to not appear in the
>in the PATH first place? (Of course without destabilizing the system
>by that.)

If you don't feel like you need to run that executable, and the
window manager works ok without it, I don't see why it would be
a problem to remove it from $PATH.

>There's no files in '/usr/local/sbin' (on my system); no admins with
>special tools desires.
>
>I don't seem to use executables from all the 'sbin' directories; I'm
>positive I need /usr/bin, /bin, and I've also installed some things
>in /usr/local/bin. It seems to me that, as a normal user, the PATH
>(and with it the path-search) could be drastically reduced. Is there
>a method to only have them in the PATH when 'sudo'ing any programs
>that require root privileges and the privileged programs in 'sbin'?

Yes, `sudo` can be configured to set $PATH for the programs that
it invokes; see sudoers(5) and look for `secure_path`.  If you
don't invoke those from your normal shell, I don't see a problem
removing them from the default.

>I mean, if I 'sodo' a shell I get - and I think this is sensible! -
>only /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>(no 'lightdm', no 'games', and no personal settings) anyway, and I
>seem to have those entries available independent of any parent
>process's setting;  PATH=/usr/bin sudo ksh  will still provide all
>the 'sbin' directories in the privileged shell's own PATH setting.
>
>So my thought is, for the moment as a workaround, to edit the PATH
>in the .profile, and _remove_ all 'sbin' and the 'lightdm' entries,
>or just explicitly _define_ PATH without the spurious parts). (Or
>would it be advisable to do that change in all the shells' .rc
>files?) Or is there yet a better place to "fix" things system-wide?
>
>(Or better not touch a running system? - but it looks so messy!)

Personally, I'd let well enough alone, but I suppose this
alludes to a larger question: does having those entries in $PATH
affect the operation of the system in any materially negative
way?  Is this just a preference for tidiness kind of thing?

There's no harm in cleaning up, but I suspect any marginal
resource savings has already been offset by thinking about it
at all.  :-)

What is the desired end-state here?

	- Dan C.