🚀 go-pugleaf

On 6/5/18 9:44 AM, DMcCunney wrote:
> This forum is a repository of computer history

Not really.

Try the Unix Historical Society mailing list tu...@tuhs.org

That's where the Unix greybeards hang out.

I thought /sbin was something SunOS introduced as something needed for NFS and diskless workstations.

DMcCunney <dennis....@gmail.com> writes:
>This came up elsewhere, but hasn't gotten a definitive answer.  This 
>forum is a repository of computer history, so someone here might know.
>
>When did the /sbin directory first appear in Unix, and who did it?

Somewhere around SVR4.   Originally it was for statically-linked
binaries that were required when /usr was a mount point and libs.so
was under /usr/lib.


>
>It *doesn't* exist in the AT&T SysVR2 version running on my AT&T 3B1 
>from the late 80s.  (And I asked Unix co-creator Brian Kernighan and he 
>didn't know, which indicates it wasn't a Bell Labs introduction.)
>
>Links I've followed make it look like it was a side-effect of the 
>attempt to fuse System V and BSD that resulted in Solaris, but I can't 
>find a definitive statement.  (I've never used BSD and have no idea what 
>it brought to the table.)
>
>If anyone here can nail this down, information will be gratefully accepted.
>
>Thanks in advance,
>______
>Dennis

On 06/05/2018 11:16 AM, Scott Lurndal wrote:
> Somewhere around SVR4.   Originally it was for statically-linked binaries 
> that were required when /usr was a mount point and libs.so was under 
> /usr/lib.

I'm not tracking why /sbin was created to deal with things under /usr.

Was /bin a sym-link to /usr/bin before this?  I thought that was a 
Solaris thing.

I get needing dependent libraries or static linking.  But I would have 
thought that any libraries that things in /bin needed would be in /lib.

I always viewed /(root) and /usr and /usr/local as three very distinct 
hierarchies.  (That's part of why the /bin sym-link to /usr/bin bugged 
me so much.)



-- 
Grant. . . .
unix || die

On Tue, 5 Jun 2018 20:51:40 -0600
Grant Taylor <gta...@tnetconsulting.net> wrote:

> On 06/05/2018 11:16 AM, Scott Lurndal wrote:
> > Somewhere around SVR4.   Originally it was for statically-linked
> > binaries that were required when /usr was a mount point and libs.so was
> > under /usr/lib.

	That accords with my understanding - it has changed since.

> I'm not tracking why /sbin was created to deal with things under /usr.
> 
> Was /bin a sym-link to /usr/bin before this?  I thought that was a 
> Solaris thing.

	I think it was, /bin and /usr/bin are still quite distinct in
FreeBSD and Centos 6 (OK still is a bit string for Centos 6).

> I get needing dependent libraries or static linking.  But I would have 
> thought that any libraries that things in /bin needed would be in /lib.

	Yep, and the stuff in /sbin is dynamically linked now. There's
a /rescue with a statically linked all-in-one (like busybox) with 144 links
for use when things are really hosed.

> I always viewed /(root) and /usr and /usr/local as three very distinct 
> hierarchies.  (That's part of why the /bin sym-link to /usr/bin bugged 
> me so much.)

	Agreed, one of the things I like about FreeBSD is that this
distinction is still maintained.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Wed, 06 Jun 2018 09:35:38 GMT, Ahem A Rivet's Shot
<ste...@eircom.net> wrote: 

> On Tue, 5 Jun 2018 20:51:40 -0600
> Grant Taylor <gta...@tnetconsulting.net> wrote:
> 
>> On 06/05/2018 11:16 AM, Scott Lurndal wrote:
>> > Somewhere around SVR4.   Originally it was for statically-linked
>> > binaries that were required when /usr was a mount point and libs.so
>> > was under /usr/lib.
> 
>      That accords with my understanding - it has changed since.
> 
>> I'm not tracking why /sbin was created to deal with things under
>> /usr. 
>> 
>> Was /bin a sym-link to /usr/bin before this?  I thought that was a 
>> Solaris thing.
> 
>      I think it was, /bin and /usr/bin are still quite distinct in
> FreeBSD and Centos 6 (OK still is a bit string for Centos 6).
> 
>> I get needing dependent libraries or static linking.  But I would
>> have thought that any libraries that things in /bin needed would be
>> in /lib. 
> 
>      Yep, and the stuff in /sbin is dynamically linked now. There's
> a /rescue with a statically linked all-in-one (like busybox) with 144
> links for use when things are really hosed.
> 
>> I always viewed /(root) and /usr and /usr/local as three very
>> distinct hierarchies.  (That's part of why the /bin sym-link to
>> /usr/bin bugged me so much.)
> 
>      Agreed, one of the things I like about FreeBSD is that this
> distinction is still maintained.
> 

Having come from the "simpler" DOS world of total control, with maybe 
just a path to c:\utils, I found it a puzzle that there were so many 
places (yet only those ones!) to put executables under linux.

-- 
Bah, and indeed, Humbug.

Grant Taylor <gta...@tnetconsulting.net> writes:
>On 06/05/2018 11:16 AM, Scott Lurndal wrote:
>> Somewhere around SVR4.   Originally it was for statically-linked binaries 
>> that were required when /usr was a mount point and libs.so was under 
>> /usr/lib.
>
>I'm not tracking why /sbin was created to deal with things under /usr.

Because there was no /lib, if I recall correctly.

On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
> Having come from the "simpler" DOS world of total control, with maybe 
> just a path to c:\utils, I found it a puzzle that there were so many 
> places (yet only those ones!) to put executables under linux.

You can put executables in a LOT of places.  You just need to choose 
somewhere that's already in the PATH environment variable, or modify it 
to your liking.

I personally have ~/bin first in my path.



-- 
Grant. . . .
unix || die

On 06/06/2018 08:25 AM, Scott Lurndal wrote:
> Because there was no /lib, if I recall correctly.

Wha???

So where did the libraries that were dynamically linked live?

Or am I mistaking no /lib to generically and incorrectly thinking there 
wasn't /usr/lib or /var/lib or <anything>/lib?



-- 
Grant. . . .
unix || die

Grant Taylor <gta...@tnetconsulting.net> writes:
>On 06/06/2018 08:25 AM, Scott Lurndal wrote:
>> Because there was no /lib, if I recall correctly.
>
>Wha???
>
>So where did the libraries that were dynamically linked live?

/usr/lib.

That's why /sbin existed, to hold executables like sh and mount that were
required to add /usr to the filesystem tree.

>From the svr4.2es/mp base pkginfo file:

d sysdir / 755 root sys 1 NULL NULL
d sysdir /bck 775 root sys
d sysdir /config 775 root bin 2 NULL NULL
d sysdir /dev 775 root sys 1 NULL NULL
d sysdir /etc 775 root sys 1 NULL NULL
d sysdir /export 775 root sys
d sysdir /home 775 root sys
d sysdir /install 775 root sys
d sysdir /installr 775 root sys
d sysdir /mnt 775 root sys
d sysdir /opt 775 root sys
d sysdir /proc 555 root root
d sysdir /save 775 root sys
d sysdir /sbin 775 root sys 1 NULL NULL
d sysdir /tmp 1777 bin bin 1 NULL NULL
d sysdir /usr 775 root sys 1 NULL NULL
d sysdir /var 775 root sys 1 NULL NULL
s sysdir /bin=/usr/bin
s sysdir /lib=/usr/lib
s sysdir /shlib=/usr/lib

note that /lib (and /bin) are symbolic links to /usr/lib and /usr/bin.

On 06/06/2018 10:11 AM, Scott Lurndal wrote:
> That's why /sbin existed, to hold executables like sh and mount that 
> were required to add /usr to the filesystem tree.

ACK

Thank you for the information.

I've not experienced much of this history mostly being exposed to Linux 
or AIX / Solaris / HP-UX in the last 10 years.

> From the svr4.2es/mp base pkginfo file:

I assume that's Sys V Release 4.2 (ES)?

> note that /lib (and /bin) are symbolic links to /usr/lib and /usr/bin.

ACK

It's good to know that /{bin,lib} linking to /usr/{bin/lib} 
(respectively) is much older than I originally thought.



-- 
Grant. . . .
unix || die

Grant Taylor <gta...@tnetconsulting.net> writes:
>On 06/06/2018 10:11 AM, Scott Lurndal wrote:
>> That's why /sbin existed, to hold executables like sh and mount that 
>> were required to add /usr to the filesystem tree.
>
>ACK
>
>Thank you for the information.
>
>I've not experienced much of this history mostly being exposed to Linux 
>or AIX / Solaris / HP-UX in the last 10 years.
>
>> From the svr4.2es/mp base pkginfo file:
>
>I assume that's Sys V Release 4.2 (ES)?

 Yes, System V Release 4.2 (ES/MP)

ES stood for 'enhanced security' (orange book B level) and MP stood
for Multiprocessor (scaled to high processor counts).  Introduced
light-weight processes and threads to the user-level API.  A pretty
significant rewrite of SVR4 to add fine-grained locking.

Later known as Unixware 2.0.

On Wed, 2018-06-06, Grant Taylor wrote:
> On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
>> Having come from the "simpler" DOS world of total control, with maybe 
>> just a path to c:\utils, I found it a puzzle that there were so many 
>> places (yet only those ones!) to put executables under linux.

It's a bit puzzling, but not a problem in practice.

> You can put executables in a LOT of places.  You just need to choose 
> somewhere that's already in the PATH environment variable, or modify it 
> to your liking.

I'm happy I don't see a lot of software installed under /opt anymore.
That was a pain: often as a user I had to add /opt/$foo/bin to my
$PATH, for each piece of software $foo I was interested in.  And quite
often such software needed other environment variables like $FOO_PATH
too, or it would malfunction.

There's also the issue with documentation.  If a piece of software is
in your path, but the man command cannot find the manual page, you're
in an awkward situation.  man(1) on Linux nowadays has the option to
search for man pages in $foo/man/ if $foo/bin is in the $PATH, but I
think that's a recent improvement.

> I personally have ~/bin first in my path.

It's unclear to me if that's standardized, but yes, I make sure I have
that in my $PATH, too.  It's where all scripts go that are only
interesting to me.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

Jorgen Grahn <grahn...@snipabacken.se> writes:
>On Wed, 2018-06-06, Grant Taylor wrote:
>> On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
>>> Having come from the "simpler" DOS world of total control, with maybe 
>>> just a path to c:\utils, I found it a puzzle that there were so many 
>>> places (yet only those ones!) to put executables under linux.
>
>It's a bit puzzling, but not a problem in practice.
>
>> You can put executables in a LOT of places.  You just need to choose 
>> somewhere that's already in the PATH environment variable, or modify it 
>> to your liking.
>
>I'm happy I don't see a lot of software installed under /opt anymore.
>That was a pain: often as a user I had to add /opt/$foo/bin to my
>$PATH, for each piece of software $foo I was interested in.  And quite
>often such software needed other environment variables like $FOO_PATH
>too, or it would malfunction.
>
>There's also the issue with documentation.  If a piece of software is
>in your path, but the man command cannot find the manual page, you're
>in an awkward situation.  man(1) on Linux nowadays has the option to
>search for man pages in $foo/man/ if $foo/bin is in the $PATH, but I
>think that's a recent improvement.

All man utilities have supported $MANPATH since basically forever.

e.g. from SVR4 man.c:

main(argc, argv)
        int argc;
        char *argv[];
{
        char section, subsec;
        char *mp;
        char *cmdname;

        int mrc; /* manual() return code */

        /* If defined, use environment value as default manual path list. */
        if ((mp = getenv("MANPATH")) != NULL)
                manpath = mp;

>
>> I personally have ~/bin first in my path.
>
>It's unclear to me if that's standardized, but yes, I make sure I have
>that in my $PATH, too.  It's where all scripts go that are only
>interesting to me.

It only needs to be at the _front_ of $PATH if you intend to
override utilities of the same name that exist under earlier
entries in $PATH.

On 06/06/2018 01:37 PM, Jorgen Grahn wrote:
> I'm happy I don't see a lot of software installed under /opt anymore. 
> That was a pain: often as a user I had to add /opt/$foo/bin to my $PATH, 
> for each piece of software $foo I was interested in.  And quite often 
> such software needed other environment variables like $FOO_PATH too, 
> or it would malfunction.

I always disliked /opt too.

As for the PATH environment variable, I tended to leave it close to the 
default.  I would actually add sym-links from /usr/bin to /opt/$FOO/bin/*.



-- 
Grant. . . .
unix || die

On 06/06/2018 11:51 AM, Scott Lurndal wrote:
> Yes, System V Release 4.2 (ES/MP)

Thank you for the clarification and explanation.



-- 
Grant. . . .
unix || die

On Wed, 2018-06-06, Scott Lurndal wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>On Wed, 2018-06-06, Grant Taylor wrote:
>>> On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
>>>> Having come from the "simpler" DOS world of total control, with maybe 
>>>> just a path to c:\utils, I found it a puzzle that there were so many 
>>>> places (yet only those ones!) to put executables under linux.
>>
>>It's a bit puzzling, but not a problem in practice.
>>
>>> You can put executables in a LOT of places.  You just need to choose 
>>> somewhere that's already in the PATH environment variable, or modify it 
>>> to your liking.
>>
>>I'm happy I don't see a lot of software installed under /opt anymore.
>>That was a pain: often as a user I had to add /opt/$foo/bin to my
>>$PATH, for each piece of software $foo I was interested in.  And quite
>>often such software needed other environment variables like $FOO_PATH
>>too, or it would malfunction.
>>
>>There's also the issue with documentation.  If a piece of software is
>>in your path, but the man command cannot find the manual page, you're
>>in an awkward situation.  man(1) on Linux nowadays has the option to
>>search for man pages in $foo/man/ if $foo/bin is in the $PATH, but I
>>think that's a recent improvement.
>
> All man utilities have supported $MANPATH since basically forever.

Yes, but that was not what I was talking about -- I was talking about
when man(1) also reads $PATH.

>>> I personally have ~/bin first in my path.
>>
>>It's unclear to me if that's standardized, but yes, I make sure I have
>>that in my $PATH, too.  It's where all scripts go that are only
>>interesting to me.
>
> It only needs to be at the _front_ of $PATH if you intend to
> override utilities of the same name that exist under earlier
> entries in $PATH.

I was going to comment on that, but didn't bother.  I put ~/bin
last in my path; seems to me overriding a standard utility would
almost always be the wrong solution to a problem.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

Huge <Huge@nowhere.much.invalid> writes:
>On 2018-06-07, Jorgen Grahn <grahn...@snipabacken.se> wrote:
>> On Wed, 2018-06-06, Scott Lurndal wrote:
>>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>>>On Wed, 2018-06-06, Grant Taylor wrote:
>
>[27 lines snipped]
>
>>>>> I personally have ~/bin first in my path.
>>>>
>>>>It's unclear to me if that's standardized, but yes, I make sure I have
>>>>that in my $PATH, too.  It's where all scripts go that are only
>>>>interesting to me.
>>>
>>> It only needs to be at the _front_ of $PATH if you intend to
>>> override utilities of the same name that exist under earlier
>>> entries in $PATH.
>>
>> I was going to comment on that, but didn't bother.  I put ~/bin
>> last in my path; seems to me overriding a standard utility would
>> almost always be the wrong solution to a problem.
>
>+1

Almost always.  I have it first in the path.

I use ksh.   Ksh has a built-in alias 'r' that interacts
with the shell history

r='hist -s'

I often type 'r x' to replay the last 'xrn' command, but sometimes
the space bar doesn't register (and the xterm window is partially
obscured), so I end up invoking the 'rx'
utility (part of the {XYZ}modem receive code), and there's no
easy way to exit it.

Putting a symbolic link in ~/bin for rx pointing to /bin/true
solves this problem.

Sure, I could remove the package containing rx (I'll likely never use
xmodem style transfers - they've been obsolete for close to two
decades), but it's easier to just catch it in ~/bin.

On 7 Jun 2018 12:18:11 GMT
Jorgen Grahn <grahn...@snipabacken.se> wrote:

> I was going to comment on that, but didn't bother.  I put ~/bin
> last in my path; seems to me overriding a standard utility would
> almost always be the wrong solution to a problem.

	The only[1] problem I know of that it's the right solution to is
hoodwinking the sysop.

[1] OK OK mocking for test purposes and ...

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On 2018-06-06, Grant Taylor <gta...@tnetconsulting.net> wrote:

> On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
>
>> Having come from the "simpler" DOS world of total control, with maybe 
>> just a path to c:\utils, I found it a puzzle that there were so many 
>> places (yet only those ones!) to put executables under linux.
>
> You can put executables in a LOT of places.  You just need to choose 
> somewhere that's already in the PATH environment variable, or modify it 
> to your liking.
>
> I personally have ~/bin first in my path.

Isn't that considered a security risk?  If a bad guy creates a piece
of malware and calls it "ls", it's much easier to slip it into ~/bin
than into /bin.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>On 2018-06-06, Grant Taylor <gta...@tnetconsulting.net> wrote:
>
>> On 06/06/2018 07:13 AM, Kerr-Mudd,John wrote:
>>
>>> Having come from the "simpler" DOS world of total control, with maybe 
>>> just a path to c:\utils, I found it a puzzle that there were so many 
>>> places (yet only those ones!) to put executables under linux.
>>
>> You can put executables in a LOT of places.  You just need to choose 
>> somewhere that's already in the PATH environment variable, or modify it 
>> to your liking.
>>
>> I personally have ~/bin first in my path.
>
>Isn't that considered a security risk?  If a bad guy creates a piece
>of malware and calls it "ls", it's much easier to slip it into ~/bin
>than into /bin.

For root, sure.  For joe user?  Not so much. If someone can access my
bin directory, all bets are already off.

On Thu, 07 Jun 2018 17:22:43 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> >Isn't that considered a security risk?  If a bad guy creates a piece

	Yep.

> >of malware and calls it "ls", it's much easier to slip it into ~/bin
> >than into /bin.
> 
> For root, sure.  For joe user?  Not so much. If someone can access my
> bin directory, all bets are already off.

	Root can access your bin directory and therein lies the risk, if
you can get a sysadmin to inherit your path while trying to solve a
'problem' you've cooked up (eg. by typing su in your session) then you can
get your ls script to run as root - it probably then leaves you a setuid
backdoor and runs the real ls. It used to be a pretty standard student
stunt back in the day.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On 06/07/2018 06:18 AM, Jorgen Grahn wrote:
> seems to me overriding a standard utility would almost always be the 
> wrong solution to a problem.

Maybe, maybe not.

Keep in mind, I'm only superseding / augmenting system commands that I 
want to run differently than they do by default.

I have ~/bin first in my path.  I have a number of utilities that 
require root permission (gained via sudo) that I run ALL THE TIME (as in 
daily, some many times a day).

So I have a wrapper [1] that I put in ~/bin for things like ip, netstat, 
ifconfig, route, etc so that I can type commands into my unprivileged 
user's shell exactly the same way that I would type them in root's shell.

I don't have to worry about needing to prefix commands with sudo (et al) 
or not.
I don't have to worry about using different formats of commands in 
different contexts.
I don't have to worry about escaping special characters to make it 
through sudo.
Etc.

I personally consider removing all the above mental load and making the 
computer do what I want to be a good thing.  Thus I consider it to be 
the proper solution.

There is also the fact that I have a LOT of commands in ~/bin that don't 
exist anywhere else that I use hourly (while at the computer).  So 
having them in a directory that is last in the PATH means that the shell 
has to traverse more directories to find them.

Aside:  I use a lot of extremely small shell scripts instead of aliases 
because I want to also be able to use the same shell scripts from within 
other locations where aliases don't apply, like non-interactive ssh 
remote command execution or other shell scripts.

What if I want a specific version of a command later in the PATH 
priority that gets superseded by a different version that is earlier in 
the PATH priority?  Having ~/bin first in the PATH allows me to make a 
sym-link to the version that I want.  Thus the version that I want is 
found and supersedes the version I want to avoid.

Finally, remember that we're talking about a user's PATH, not the system 
wide PATH.  Which means (to me) that it's up to the given user to 
configure things the way that they want.  Far be it for me to tell you 
what you should and should not do.

[1] Link - Sudify
      - https://dotfiles.tnetconsulting.net/tools/sudify/sudify.html



-- 
Grant. . . .
unix || die

Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On Thu, 07 Jun 2018 17:22:43 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> >Isn't that considered a security risk?  If a bad guy creates a piece
>
>	Yep.
>
>> >of malware and calls it "ls", it's much easier to slip it into ~/bin
>> >than into /bin.
>> 
>> For root, sure.  For joe user?  Not so much. If someone can access my
>> bin directory, all bets are already off.
>
>	Root can access your bin directory and therein lies the risk, if
>you can get a sysadmin to inherit your path while trying to solve a
>'problem' you've cooked up (eg. by typing su in your session) then you can
>get your ls script to run as root - it probably then leaves you a setuid
>backdoor and runs the real ls. It used to be a pretty standard student
>stunt back in the day.

If I were using a system shared with _anyone_ else, I'd worry about it;
but that's pretty uncommon outside corporate firewalls.

In any case, if someone gets root, again, all bets are already off
(su - user, anyone?)

On 06/07/2018 11:49 AM, Ahem A Rivet's Shot wrote:
> Root can access your bin directory and therein lies the risk

The root user accessing your bin directory is NOT a problem.  There's 
also extremely little that you can do to prevent root from accessing 
your directory.

> if you can get a sysadmin to inherit your path while trying to solve a 
> 'problem' you've cooked up (eg. by typing su in your session) then you 
> can get your ls script to run as root

That is an entirely different problem.  Specifically it's one where 
unsafe environment was carried over to a privileged user.

This is EXACTLY why sudo (etc) sanitize the environment first.

Root /accessing/ files in your bin directory is COMPLETELY DIFFERENT 
than root /running/ files in your bin directory.



-- 
Grant. . . .
unix || die

On Thu, 7 Jun 2018 12:46:55 -0600
Grant Taylor <gta...@tnetconsulting.net> wrote:

> On 06/07/2018 11:49 AM, Ahem A Rivet's Shot wrote:
> > Root can access your bin directory and therein lies the risk
> 
> The root user accessing your bin directory is NOT a problem.  There's 
> also extremely little that you can do to prevent root from accessing 
> your directory.

	Yeah OK I should have said execute stuff in your bin directory.

> > if you can get a sysadmin to inherit your path while trying to solve a 
> > 'problem' you've cooked up (eg. by typing su in your session) then you 
> > can get your ls script to run as root
> 
> That is an entirely different problem.  Specifically it's one where 
> unsafe environment was carried over to a privileged user.

	This is the problem cause by having `/bin first in the path which
is what was under discussion.

> This is EXACTLY why sudo (etc) sanitize the environment first.

	Yep but not not su which was all that was around when this was a
common student stunt.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Thu, 07 Jun 2018 18:45:00 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Ahem A Rivet's Shot <ste...@eircom.net> writes:
> >On Thu, 07 Jun 2018 17:22:43 GMT
> >scott@slp53.sl.home (Scott Lurndal) wrote:
> >
> >> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> >> >Isn't that considered a security risk?  If a bad guy creates a piece
> >
> >	Yep.
> >
> >> >of malware and calls it "ls", it's much easier to slip it into ~/bin
> >> >than into /bin.
> >> 
> >> For root, sure.  For joe user?  Not so much. If someone can access my
> >> bin directory, all bets are already off.
> >
> >	Root can access your bin directory and therein lies the risk, if
> >you can get a sysadmin to inherit your path while trying to solve a
> >'problem' you've cooked up (eg. by typing su in your session) then you
> >can get your ls script to run as root - it probably then leaves you a
> >setuid backdoor and runs the real ls. It used to be a pretty standard
> >student stunt back in the day.
> 
> If I were using a system shared with _anyone_ else, I'd worry about it;
> but that's pretty uncommon outside corporate firewalls.

	True enough - and it is only multi-user systems where there are
unprivileged users unscrupulous enough to try and con their way to root
access.

> In any case, if someone gets root, again, all bets are already off
> (su - user, anyone?)

	The problem is *you* getting root when you're not supposed to.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Thu, 2018-06-07, Grant Taylor wrote:
> On 06/07/2018 06:18 AM, Jorgen Grahn wrote:
>> seems to me overriding a standard utility would almost always be the 
>> wrong solution to a problem.
>
> Maybe, maybe not.
>
> Keep in mind, I'm only superseding / augmenting system commands that I 
> want to run differently than they do by default.
>
> I have ~/bin first in my path.  I have a number of utilities that 
> require root permission (gained via sudo) that I run ALL THE TIME (as in 
> daily, some many times a day).
>
> So I have a wrapper [1] that I put in ~/bin for things like ip, netstat, 
> ifconfig, route, etc so that I can type commands into my unprivileged 
> user's shell exactly the same way that I would type them in root's shell.

Most of those don't need root privileges for reading (although some
Linux distributions annoyingly put them in /sbin and don't put /sbin
in $PATH for normal users).  I think it's useful to have them
available and to know you cannot break anything unless you
specifically choose to.

> I don't have to worry about needing to prefix commands with sudo (et al) 
> or not.
> I don't have to worry about using different formats of commands in 
> different contexts.
> I don't have to worry about escaping special characters to make it 
> through sudo.
> Etc.

I'd worry about scripts picking up the wrong copy of ip, netstat and
friends, and run stuff as root (and log a sudo use) when they really
just want read access.

> I personally consider removing all the above mental load and making the 
> computer do what I want to be a good thing.  Thus I consider it to be 
> the proper solution.

My time to stick my neck out:

I don't like sudo.  I'd much rather su to root in a separate shell,
and carefully do my privileged work there, then log out when I'm done.
I don't want dangerous command lines to end up in my shell history,
where I can by accident execute them again and (if I ran sudo
recently) have them execute without warning.

Sudo blurs the distinction between me and the root user, it seems to
me.

That way I also don't have to understand the sudo config files.

> There is also the fact that I have a LOT of commands in ~/bin that don't 
> exist anywhere else that I use hourly (while at the computer).  So 
> having them in a directory that is last in the PATH means that the shell 
> has to traverse more directories to find them.
>
> Aside:  I use a lot of extremely small shell scripts instead of aliases 
> because I want to also be able to use the same shell scripts from within 
> other locations where aliases don't apply, like non-interactive ssh 
> remote command execution or other shell scripts.

I was going to mention aliases as an alternative, but that's a valid point.
Aliases are a bit ... unorthogonal.

> What if I want a specific version of a command later in the PATH 
> priority that gets superseded by a different version that is earlier in 
> the PATH priority?  Having ~/bin first in the PATH allows me to make a 
> sym-link to the version that I want.  Thus the version that I want is 
> found and supersedes the version I want to avoid.

Yes.  I haven't encountered any "false twins" like that in recent
decades, though.  Debian Linux (and probably others) has the
/etc/alternatives system for when e.g. you have two different vi
clones installed; I use that one.

/etc/alternatives is system-global though, so if I was on a multi-user
system where the sysadmin declared that Vim is the right vi and I
wanted nvi instead, I might consider doing what you do.

> Finally, remember that we're talking about a user's PATH, not the system 
> wide PATH.  Which means (to me) that it's up to the given user to 
> configure things the way that they want.  Far be it for me to tell you 
> what you should and should not do.

Same here, of course!  Whatever I write in this thread has a bunch of
"IMHO" and "YMMV" attached to it.

I found it interesting to read about how you structure your environment.

/Jorgen

> [1] Link - Sudify
>       - https://dotfiles.tnetconsulting.net/tools/sudify/sudify.html

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

On 2018-06-09, Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Thu, 2018-06-07, Grant Taylor wrote:
>> On 06/07/2018 06:18 AM, Jorgen Grahn wrote:
>>> seems to me overriding a standard utility would almost always be the 
>>> wrong solution to a problem.
>>
>> Maybe, maybe not.
>>
>> Keep in mind, I'm only superseding / augmenting system commands that I 
>> want to run differently than they do by default.
>>
>> I have ~/bin first in my path.  I have a number of utilities that 
>> require root permission (gained via sudo) that I run ALL THE TIME (as in 
>> daily, some many times a day).
>>
>> So I have a wrapper [1] that I put in ~/bin for things like ip, netstat, 
>> ifconfig, route, etc so that I can type commands into my unprivileged 
>> user's shell exactly the same way that I would type them in root's shell.
>
> Most of those don't need root privileges for reading (although some
> Linux distributions annoyingly put them in /sbin and don't put /sbin
> in $PATH for normal users).  I think it's useful to have them
> available and to know you cannot break anything unless you
> specifically choose to.
>
>> I don't have to worry about needing to prefix commands with sudo (et al) 
>> or not.
>> I don't have to worry about using different formats of commands in 
>> different contexts.
>> I don't have to worry about escaping special characters to make it 
>> through sudo.
>> Etc.
>
> I'd worry about scripts picking up the wrong copy of ip, netstat and
> friends, and run stuff as root (and log a sudo use) when they really
> just want read access.
>
>> I personally consider removing all the above mental load and making the 
>> computer do what I want to be a good thing.  Thus I consider it to be 
>> the proper solution.
>
> My time to stick my neck out:
>
> I don't like sudo.  I'd much rather su to root in a separate shell,
> and carefully do my privileged work there, then log out when I'm done.
> I don't want dangerous command lines to end up in my shell history,
> where I can by accident execute them again and (if I ran sudo
> recently) have them execute without warning.
>
> Sudo blurs the distinction between me and the root user, it seems to
> me.
>
> That way I also don't have to understand the sudo config files.
>
>
+++


-- 
greymaus.ireland.ie
Just_Another_Grumpy_Old_Man

On 06/09/2018 03:18 AM, Jorgen Grahn wrote:
> Most of those don't need root privileges for reading (although some Linux 
> distributions annoyingly put them in /sbin and don't put /sbin in $PATH 
> for normal users).  I think it's useful to have them available and to 
> know you cannot break anything unless you specifically choose to.

I do a LOT of things where I dynamically reconfigure the network or 
other similar things for virtualization labs.  As such, I find that I 
need write access to ip a LOT.

> I'd worry about scripts picking up the wrong copy of ip, netstat and 
> friends, and run stuff as root (and log a sudo use) when they really 
> just want read access.

Ya.

About the only time I've been burned by that is the differences in 
behavior of running "hostname" with options on Solaris as non-root vs 
root.  Former (silently) fails.  Latter changes the system's hostname.

> My time to stick my neck out:
> 
> I don't like sudo.  I'd much rather su to root in a separate shell, 
> and carefully do my privileged work there, then log out when I'm done.

I can respect that.

My biggest issue with that is su requires knowing root's (or the target 
user's) password.  This is okay on a single user machine.  This is NOT 
okay on multi-user systems.  This is problematic when you have many 
different teams that need to administer different parts of the system 
and all share root's credentials.

On the other hand, sudo does NOT need the target user's password (by 
default).  Instead you confirm who you are to sudo and then it allows 
you to run things.

> I don't want dangerous command lines to end up in my shell history, 
> where I can by accident execute them again and (if I ran sudo recently) 
> have them execute without warning.

Fair.

I've mostly gotten numb to that.  For better or worse.

> Sudo blurs the distinction between me and the root user, it seems to me.

Does "su" blur the distinction?  Both su and sudo cause commands to be 
run as a different user (root by default).

Or is it the fact that you start a shell as the other user?  Be it via 
"su -" or "sudo -i".

Would "sudo -i" be blurry for you?  Or is that better because you're in 
a root shell?

> That way I also don't have to understand the sudo config files.

Many (if not most) people don't need a super fancy sudoers file.  In 
fact, what most Linux distributions ship with is sufficient.  If you're 
in $GROUP, you can have sudo access.

If you work for a company and need something more complex, you'll likely 
get some training on how to manage the sudoers file.

> I was going to mention aliases as an alternative, but that's a valid 
> point.  Aliases are a bit ... unorthogonal.

I use a number of aliases.  But they tend to be for me being lazy.  I.e.

alias ag='apt-get'

By the way, I've got apt-get working via sudify too.  —  I frequently 
install / uninstall things too.

;-)

> Yes.  I haven't encountered any "false twins" like that in recent decades, 
> though.  Debian Linux (and probably others) has the /etc/alternatives 
> system for when e.g. you have two different vi clones installed; I use 
> that one.

Ya.  I tend to change the editor from nano to vim.

> /etc/alternatives is system-global though, so if I was on a multi-user 
> system where the sysadmin declared that Vim is the right vi and I wanted 
> nvi instead, I might consider doing what you do.

Yep.

> Same here, of course!  Whatever I write in this thread has a bunch of 
> "IMHO" and "YMMV" attached to it.

ACK

> I found it interesting to read about how you structure your environment.

:-)



-- 
Grant. . . .
unix || die

On Sat, 09 Jun 2018 15:33:10 -0600, Grant Taylor wrote:

>> That way I also don't have to understand the sudo config files.
> 
> Many (if not most) people don't need a super fancy sudoers file.  In
> fact,
> what most Linux distributions ship with is sufficient.  If you're in
> $GROUP, you can have sudo access.
> 
> If you work for a company and need something more complex, you'll likely
> get some training on how to manage the sudoers file.

I'd recommend this:

  https://www.michaelwlucas.com/tools/sudo


-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

On 06/09/2018 04:38 PM, Bob Eager wrote:
> I'd recommend this:
> 
>    https://www.michaelwlucas.com/tools/sudo

I concur.  Michael's Sudo Mastery book is probably one of the best 
sources of information that I've read on sudo.

I highly recommend Sudo Master.  I also recommend Michael's other 
Mastery books.



-- 
Grant. . . .
unix || die

On 06/09/2018 10:33 PM, Grant Taylor wrote:
> I concur.  Michael's Sudo Mastery book is probably one of the best 
> sources of information that I've read on sudo.

Sudo Mastery is where I learned about PAM SSH Agent Auth to enable 
authenticating to sudo (or anything else using PAM) via SSH keys.

I use it and sudo on all my personal systems and I strongly recommend it 
to anyone that will listen.

The pam-ssh-agent-auth method enables me to remove the NOPASSWD: 
parameter.  Sudo transparently authenticates using my SSH key every time 
that's necessary.  I think this leaves me in a better security posture, 
particularly with sudo.  }:-)



-- 
Grant. . . .
unix || die

On 10 Jun 2018 09:43:15 GMT
Huge <Huge@nowhere.much.invalid> wrote:

> Oh, Ghod. Takes me back to the horror of rolling out and maintaining
> sudoers files on 9000 servers at $(MEGABANK), and trying to get developers

	Yeuch! Puppet springs to mind - or maybe a cron job fetching
sudoers from a protected publishing point periodically.

> who get root for a valid reason (*), and then add themselves to the
> sudoers file, fired.

	Ah, then there are the ones who stash a setuid copy of /bin/sh
somewhere or ... The tricks of developers wanting to hang on to root access
are legion.

	I have worked in a place where there was for a while a
spectacularly incompetent sysadmin who couldn't be fired for political
reasons - certain trusted developers were *expected* to maintain root back
doors and clean up after him. Eventually I got him to trust me to help keep
him from screwing up - he was about as safe with a root password as a three
year old with a jar of nitroglycerine.

> (* Them; "We have to have root to operate our systems (+)"
> Me; "Then your systems are broken. Go away and redesign them.")

	OK - now we need root to install the redesign, it's the *last*
time ... 
	...
	...
	Erm - can we have root please, we need to fix the mess we made of
the redesign

	I recall one place where developers were running SQL commands by
hand on live production databases containing payment data to update the
schema for a software update. There was a staging environment, so they got
to practice doing it.

	It took a while to fix that one.

> (+ Mostly because they didn't understand groups and how to apply them
> to file ownership so their systems could share files.)

	Oh dear.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/