[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.

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.
>

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[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?

I generally optimize the $PATH such that most of the common
commands will hit an early component, and while one might wish
to override a system command at times, if necessary, a shell
function can be used rather than relying on the position of
the target directory in $PATH.

Note that most shells (e.g. ksh) will cache any hits and leverage the cache
on subsequent invocations.

If you 'strace' any gnome or kde application, you'll find hundreds
of failed open calls looking for shared objects, locales, caches,
and other collateral. I'd not be too worried about the impact
of extra components in the $PATH variable.

>
>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.
>