coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using t


From: Bernhard Voelker
Subject: Re: [PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using tests
Date: Wed, 23 Nov 2011 20:48:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16

On 11/23/2011 06:46 PM, Jim Meyering wrote:
> Erik Auerswald wrote:
> ...
>>> Therefore I don't think it's a problem of the system, but
>>> more the behavior of coreutils tests to use administrative
>>> tools (those usually used by root and therefore in [/usr]/sbin).
>>> As a result, I think the test should either be run as root
>>> only (which is of course often not required) or care about
>>> having /usr/sbin and /sbin in the PATH when it's using such
>>> tools.
>>
>> I'd say that's reasonable. The FHS states that
>>
>> "Utilities used for system administration (and other root-only commands)
>> are stored in /sbin, /usr/sbin, and /usr/local/sbin."
>> (http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES)
>>
>> Building software (e.g. coreutils) is not usually done with
>> an administrative account, thus PATH needs not contain the sbin
>> directories. If some test does require them, they should be added to
>> the PATH of that test.
>>
>> That said, probably some of the sbin programs should rather be in bin,
>> because they are of use for regular users as well.
> 
> The point is that the separation is not clear.
> Even /sbin programs like mkfs.* can be useful to non-root users.
> I use a few of those in parted tests.
> Also, ifconfig is useful to non-root users, yet resides in /sbin.
> 
> Thus, by omitting /sbin and /usr/sbin, that version of sudo is
> causing trouble.  Fedora made the same change to sudo, but ended
> up reverting it due to all of the trouble it caused.

It's not sudo, it's a login at the console or into X.

I only know for Solaris, HP-UX and OpenSuSE, but at least none of
those ever had /sbin, /usr/sbin or /usr/local/sbin in the PATH of
non-root users (by default).

It's clear that the separation may or may not be fortunate, but
as long it's like it is, I'd say that the tests (or even the whole
build system?) should take care about having a sane PATH to find
even those admin-but-yet-useful-for-non-root-user tools.

Berny



reply via email to

[Prev in Thread] Current Thread [Next in Thread]