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

Bug#158497: _PATH_*PATH variables in <paths.h> don't conform to debian standards

At Wed, 12 Mar 2003 14:43:52 +0100,
Robert Millan wrote:
> On Wed, Mar 12, 2003 at 12:28:28PM +0900, GOTO Masanori wrote:
> > At Tue, 11 Mar 2003 13:22:28 +0100,
> > Robert Millan wrote:
> > > > _PATH_STDPATH is derived from BSD.  I guess in past there have been
> > > > occured by some reason, but it's obsolete and only there for
> > > > historical purpose.
> > > 
> > > then there's a problem, because GNU coreutils uses it. what is the correct
> > > way now to obtain the default system path, for root and for user?
> > 
> > GNU coreutils 4.5.9 uses _PATH_STDPATH no longer.
> there's _PATH_DEFPATH in src/su.c. please can you give any hint on this one?

Well, _PATH_DEFPATH is used in src/su.c, and the result of "su -l"
(which makes the shell a login shell) becomes PATH=/usr/bin:/bin for
non-privileged user, PATH="/usr/ucb:/bin:/usr/bin:/etc" for root user.

For root user, we don't declare such variable _PATH_DEFPATH_ROOT, so
coreutils should be changed DEFAULT_ROOT_LOGIN_PATH setting as

For non-root users, yes, _PATH_DEFPATH is applied.  ...Hmm, well, in
this case DEFAULT_LOGIN_PATH is not followed by debian's definition.
But, don't hurry to answer this issue: should we still have change
glibc's paths.h?

src/su.c in coreutils separates path value between root user and
non-root users.  But imagine that if a program does not separate the
use of pathname, and uses _PATH_DEFPATH for both root and non-root
users.  You know it's not appropriate setting.  To begin with, the
whole idea of _PATH_DEFPATH is really matched in debian.  I don't
think so.  Back to glibc's paths.h, IMHO, we should modify coreutils
definition, not glibc.

BTW, debian's /bin/su is login package's.  So even if we change
_PATH_DEFPATH, it does not affect our /bin/su.  In addition, shadow
package's /bin/su don't use variables in paths.h.

At least modifying _PATH_STDPATH seems being not needed, so it can be
closed without appling your patch.

-- gotom

Reply to: