On Wed, Apr 01, 2020 at 04:10:02PM -0400, Stephen Gallagher wrote:
> On Wed, Apr 1, 2020 at 3:58 PM Lukas Czerner <lczerner@xxxxxxxxxx> wrote:
> >
> > On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
> > > On 4/1/20 4:27 AM, Lukas Czerner wrote:
> > > > I've noticed some failures in automated tests in bodhi, specifically
> > > > this one:
> > > >
> > > > {
> > > > "arch" : "x86_64",
> > > > "code" : "SuspiciousPath",
> > > > "context" : {
> > > > "excerpt" : [
> > > > "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> > > > ],
> > > > "path" : "/usr/sbin/e2scrub"
> > > > },
> > > > "diag" : "Potentially insecure PATH element <tt>/local</tt>",
> > > > "subpackage" : "e2scrub"
> > > > },
> > > >
> > > > I am not sure why it's considered insecure while on all of the Fedora
> > > > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
> > > > default part of the PATH.
> > >
> > > You don't want a system script to be looking for executables in /usr/local
> > > before the regular bin directories. And it's probably better that it
> > > doesn't look in /usr/local at all.
> > > It's fine for the admin to put extra things in /usr/local, but those paths
> > > don't override the system ones.
> >
> > Thanks, that's understandable, but then why the PATH on my system is
> >
> > /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
> >
> > or
> >
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
> >
> > all the systems I try include /usr/local in the PATH.
> >
>
> We don't want anything installed via RPM to be using /usr/local
> directly. The /usr/local path is intended for locally-installed
> content by the administrator, while /usr is meant for content coming
> from the distributor.
>
> For example, I maintain the `npm` package. It installs its binary as
> /usr/bin/npm. However, if I use npm (it's a Node.js package manager)
> to install a Node-based binary with `npm -g install someapp`, it will
> install it in /usr/local rather than /usr. This is done in part to
> avoid future conflicts where RPM might try to overwrite
> locally-installed content or where a tool like `npm` is overwriting
> RPM-managed content (which it was doing until fairly recently...)
Thanks I appreciate the explanation, but I am aware of this. What I am
trying to understand is how setting a PATH with "/local" element from a
script is insecure. When I run the scrip on my system the PATH already
include the "/local" element by default so it's not really changing
anything. Right ?
Is it that the test is using the fact that we set the PATH with "/local"
element as an indication that it's going to put something there ? It's
not the case here and in fact I think that the line should be removed
from the script, but that's besides the point. I am trying to undestand
why the test is failing and what is it protecting from.
Anyone has any idea where to find the person who is responsible for
those automated tests ?
-Lukas
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
