On 20-Apr-99, 01:05 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Apr 1999, Steve Greenland wrote:
> > And appending doesn't really help. If you assume that you can't trust
> > root's path, then you have to override it, or else you just trade one
> > set of problems ("can't find route
> > > > Consider su -c /etc/init.d/blah
Brock Rozen <[EMAIL PROTECTED]> wrote:
> What am I missing?
We have new sysadmins coming into being every hour. Learning is
heuristic. Right now, su -c ... is likely to fail for sbin/
commands.
If you change the system so that su -c is practically guaran
On Mon, 19 Apr 1999, Raul Miller wrote:
> > > Consider su -c /etc/init.d/blah
>
> > And if the PATH wasn't appended, how would su -c /etc/init.d/blah be any
> > different, except that it may not run?
>
> So? It's not as if su -c is the only issue involved. And, not running
> is only relevant
On Mon, 19 Apr 1999, Steve Greenland wrote:
> directories". My point is that if for some reason a bunch of the
> standard programs move to some other directory, then that new directory
> will need to be added to all the scripts. The scripts don't *know* what
> paths they need, except by convention
On Sun, 18 Apr 1999, Raul Miller wrote:
> > Consider su -c /etc/init.d/blah
Brock Rozen <[EMAIL PROTECTED]> wrote:
> And if the PATH wasn't appended, how would su -c /etc/init.d/blah be any
> different, except that it may not run?
So? It's not as if su -c is the only issue involved. And, not r
On 19-Apr-99, 02:26 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> Yes, it does require a lot of people to make modifications to a lot of
> scripts -- but it certainly doesn't require modifications again if the
> root path ever changes. Why? Because these script are appending what THEY
> need, ev
On Sun, 18 Apr 1999, Raul Miller wrote:
> I think that the append mechanism is bad because there are a number of
> contexts where this isn't the best solution.
>
> > The parents PATH would be inherited anyhow, wouldn't it? So we're
> > doing what to it that reduces security?
>
> Consider su -c /
On Sun, 18 Apr 1999, Steve Greenland wrote:
> > Does it hurt anything? I've yet to see anybody point out to me that it
> > does.
>
> Again: it requires that a lot of people make modifications to a lot
> scripts. It then puts us in a position that if the standard root path
> ever changes, all thos
On 18-Apr-99, 07:54 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> Does it hurt anything? I've yet to see anybody point out to me that it
> does.
Again: it requires that a lot of people make modifications to a lot
scripts. It then puts us in a position that if the standard root path
ever change
On Sun, 18 Apr 1999, Raul Miller wrote:
> > In general it's safer to fully specify root's $PATH rather than trust
> > what was inherited from the parent.
Brock Rozen <[EMAIL PROTECTED]> wrote:
> And this policy changes what?
There's several policies I've seen proposed: one specifying that root's
On Sun, 18 Apr 1999, Anthony Towns wrote:
> Alternately, something along the lines of ``Scripts must not assume
> the environment is at all sensible, and should do something like the
> following to ensure it is...'' would be fine, with the ellipses filled
> in. Just changing the PATH isn't particu
On Sun, 18 Apr 1999, Raul Miller wrote:
> In general it's safer to fully specify root's $PATH rather than trust
> what was inherited from the parent.
And this policy changes what? The parents PATH would be inherited anyhow,
wouldn't it? So we're doing what to it that reduces security?
> If we co
Brock Rozen <[EMAIL PROTECTED]> wrote:
> Essentially, my proposal is trying to solve one problem, and one problem
> only -- the inability to reach a certain program because the PATH has been
> changed/deleted/whatever. The solution to that is adding a simple PATH
> line that appends whatever PATH t
On Sun, Apr 18, 1999 at 03:54:07PM +0300, Brock Rozen wrote:
> I have to agree, and as such, I'll bounce the ball back into your court
> and ask you to improve my proposal (or make a separate one) that will
> solve the different TZ settings or whatever other problems you mentioned.
Sure.
``Script
On Sun, 18 Apr 1999, Anthony Towns wrote:
> Note: dpkg -i fails with the following warning:
> ] dpkg: `ldconfig' not found on PATH.
> ] dpkg: `start-stop-daemon' not found on PATH.
> ] dpkg: `install-info' not found on PATH.
> ] dpkg: `update-rc.d' not found on PATH.
>
> These are in /sbin, /sbin
On Sun, Apr 18, 1999 at 01:34:57PM +0300, Brock Rozen wrote:
> So we DO have to deal with an existing issue, because scripts are being
> written however the maintainer wants them to be written.
(Forgive me if I don't see this as a huge problem)
> I think the time
> for a policy has come, and tha
An additional note that somebody else posted to debian-devel (I believe)
-- this shows that there ARE scripts in /etc/init.d that set the PATH
line, and to the best of knowledge, do not even append, but just
overwrite.
So we DO have to deal with an existing issue, because scripts are being
written
17 matches
Mail list logo
