Re: Default PATH setting - reduce to something more sensible?

On 14/01/2025 13:55, Dan Cross wrote:

[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'?

I'd say that anything in 'sbin' should be considered here-be-dragons, if you really want to run that, then you should be made to type the whole path - just as a safety net.

 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.