Paul Wouters wrote: This really seems a bit unreal. If you want /sbin and /usr/sbin in your path, well`ifconfig` is _also_ for system administrators. Regular users — my Oracle DBAs, say —Those aren't "regular users" by a /very/ long shot in my book.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").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.Use aliases.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.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.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".Conversely, utilities that non-root users should not be allowed to use need to be protected in an effective manner;... 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...This is not a security issue. No security is gained from needing to type "/sbin/ifconfig" over "ifconfig".and removing the directory from their path is not it. This isn't even security by obscurity, it's security by obtuseness.It has nothing whatsoever to do with security, and everything with not confusing random users with commands they can't use sensibly.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 gee, that's what .profile or .bash_profile is for. Where in the world did this idea of "root only" commands come from? If these were truly "root only" commands, then /sbin and /usr/sbin would have 700 permissions. Long, apparently too long ago, /sbin (and /usr/sbin) were reserved by informal convention for commands that were statically linked, and thus did not require libs from /usr/lib, back in the days when there was no /lib, so that on a flaky or corrupt system where /usr could not be mounted for some reason, some few commands could still be run to restore the system. One of the fundamental principles of *nix was that the user was presumed to know what they were doing. That seems to no longer be the case with Linux. -- === Ron Watson === rw@xxxxxxxxxxxxxx === Nisi potestatam dabis, non habebunt. |
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list