<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Paul Wouters wrote:
<blockquote
cite="midPine.LNX.4.63.0605082152050.19729@tla.xelerance.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">`ifconfig` is _also_ for system administrators. Regular users — my
Oracle DBAs, say —
</pre>
</blockquote>
<pre wrap="">Those aren't "regular users" by a /very/ long shot in my book.
</pre>
</blockquote>
<pre wrap=""><!---->
In that case, there are no "regular users" on most linux servers. In which
case you only make the case for allowing commands like ifconfig to be used
by everyone (since most linux servers have no "regular users").
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I also find it annoying that I either have to type the full path —
particularly as it means I have to remember which of
/bin:/usr/bin:/sbin:/usr/sbin the utility in questions resides in — or
become root just to check ifconfig output.
</pre>
</blockquote>
<pre wrap="">Use aliases.
</pre>
</blockquote>
<pre wrap=""><!---->
The point here was not that it was impossible to overcome. The point being
made was that a majority of the users want commands in /sbin and /usr/sbin
to be in their path, even if they do not have root permission on them.
</pre>
<blockquote type="cite">
<pre wrap="">They are in /bin and /usr/bin. What is in /sbin or /usr/sbin is /not/ for
regular user consumption. If they need it, they aren't regular users.
</pre>
</blockquote>
<pre wrap=""><!---->
You are confusing "regular users" with "endusers that only click icons".
Those click-users are not running a terminal window, so they have no
issues with wether there are 2500 or 3000 commands in their path. However,
those who do run a terminal, tend to really enjoy using commands like
"ip", "ifconfig", "ping" and "traceroute".
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Conversely, utilities that non-root users should not be allowed to use
need to be protected in an effective manner;
</pre>
</blockquote>
<pre wrap="">... by permission to run only by selected user/group, by internal checks in
the utility, by permission checks in the kernel; where you /must/ rely
only on the last for real security, just exactly as this has worked from
day one (or thereabouts) in Unix...
</pre>
</blockquote>
<pre wrap=""><!---->
This is not a security issue. No security is gained from needing to type
"/sbin/ifconfig" over "ifconfig".
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> and removing the directory
from their path is not it. This isn't even security by obscurity, it's
security by obtuseness.
</pre>
</blockquote>
<pre wrap="">It has nothing whatsoever to do with security, and everything with not
confusing random users with commands they can't use sensibly.
</pre>
</blockquote>
<pre wrap=""><!---->
Oh come on. A lot of unix commands are two letters long. This has nothing to
do with protecting the user, and has all to do with sysadmins wanting to
cut down on typing. 2500 vs 3000 commands is not going to make a different to
the enduser that "needs protection".
And on the other side, if we do believe we need to help and protect these users,
then i should file a bug report against "cal 5" because it displays the year 5
instead of the current year, fifth month.
Let's dump some legacy guys. I can understand /foo versus /usr/foo, as we can
still do shared /usr readonly mounts, but the distinction between /bin and /sbin
is silly. And that's why people here are annoyed by it, they always have to make
this change on any fresh install of redhat.
Paul
</pre>
</blockquote>
This really seems a bit unreal. If you want /sbin and /usr/sbin in your
path, well<br>
gee, that's what .profile or .bash_profile is for. Where in the world
did this idea<br>
of "root only" commands come from? If these were truly "root only"
commands,<br>
then /sbin and /usr/sbin would have 700 permissions. Long, apparently
too long<br>
ago, /sbin (and /usr/sbin) were reserved by informal convention for
commands<br>
that were statically linked, and thus did not require libs from
/usr/lib, back in<br>
the days when there was no /lib, so that on a flaky or corrupt system
where /usr<br>
could not be mounted for some reason, some few commands could still be
run<br>
to restore the system. One of the fundamental principles of *nix was
that the<br>
user was presumed to know what they were doing. That seems to no longer
be<br>
the case with Linux.<br>
<br>
<br>
<pre class="moz-signature" cols="255">--
=== Ron Watson === <a class="moz-txt-link-abbreviated" href="mailto:rw@compukitty.com">rw@compukitty.com</a> ===
Nisi potestatam dabis, non habebunt.
</pre>
</body>
</html>