When I run "sudo /sbin/mkinitrd", /sbin isn't in my path. This causes mkinitrd to fail when it runs depmod. My fix is to instead have it run /sbin/depmod with the following very simple patch:

I vote for this, as (1) it's a trivial patch, and (2) it's good scripting practice to specify full paths for executables, especially in system-critical scripts.

And if you take my advice, I suggest you read my tag line. It's very pertinent for you, and me, in this moment.

Never have issues like this.

# su -
# mkinitrd

Naturally, that works because it loads root's PATH and other environment. I'm specifically trying to make mkinitrd work with sudo. The reason is I've written a Slackware installation guide for work and I want as few steps as possible, and I especially wish to avoid passwords so I can instead have long sequences of commands that can be pasted in.

Is there any good reason that we shouldn't just add the /sbin paths to the regular user $PATH and end this nonsense once and for all? It's not like we get any extra security from having different root and regular user paths - users could always try to execute things anyway by providing the path to the binary. It would sure stop a lot of common problems with using su/sudo.

2 members found this post helpful.

I've been doing that for myself for a long time and other then occasionally getting a lot of warnings when trying to use installpkg/upgradepkg/removepkg as a regular user accidentally I haven't noticed any issues.

1 members found this post helpful.

volkerdi --

None that I know of ( I wondered more-or-less the same thing in another rairly-recent thread )

And /etc/profile could be simplified a tad too !

You've got my vote ( if that matters )

-- kjh

An alternative to patching mkinitrd would be to edit the /etc/sudoers file (since you have to modify it anyway to give a user access to it) to uncomment the line that sets default paths, which includes the sbin directories.

It should be noted that using sudo is not a normal thing for many Slackers. The concept of using sudo to run all administrative commands is something introduced by Ubuntu to simplify administration, but it also makes security a bit worse. sudo was originally designed to allow system administrators to give certain users the ability to run a limited set of commands with elevated permissions.

In regards to your guide, I'm not sure that having a user add themselves to the /etc/sudoers file is the best thing in a Slackware guide. It might be better to introduce them to su - rather than editting the sudoers file... especially since that will work on any system out of the box and doesn't require manually editing a file to make it happen.

I've been adding my main user to the /sbin/ paths for many, many years. It gives a regular user access to utilities that they are allowed to run, but are hidden in /sbin/ or /usr/sbin/, like lspci. You can get some good info from lspci as a regular user. I'm sure there's plenty of other examples, but I'm too lazy to look into them. As you said, the security isn't a great reason since users can just run it with the full path. Users will either get an error message or limited access to the program, but I don't really see any downsides (except for confusion by some when they run removepkg as a user and it just spits out errors).

It'd be awesome to add the sbin paths to all users on the next version of Slackware.

1 members found this post helpful.

I was taught that any script that calls external utilities should not assume anything about its runtime environment and should always explicitly set its PATH. Adding {/usr,}/sbin to the users PATH is not going to fix the underlying issue.

mkinitrd should not fail just because the PATH doesn't contain /sbin. Whether that absence is by default or explicitly set by the user is IMO irrelevant.


As for adding sbin to non-root users PATHs, I don't see the value in adding lots of executables they just can't run to the PATH. The whole /sbin,/usr/sbin/,/bin,/usr/bin thing is just a mess anyway as Rob Landley so clearly described 8 years ago. The entire thing needs reevaluating.

IMO Fedora were on the right track with the /{bin,sbin,lib} -> /usr thing, but sbin needs more thought: on the one hand it contains system daemons like udevd, on the other it also contains user utilities like udevadm. Those two don't feel like they belong in the same directory to me - one is intended to be run by users (though in this case specifically root) and should be in the path, the other is a system component and arguably shouldn't be in the path.

Like I said, one big mess; though probably not one that Pat wants to grapple with as it would be a lot of work to clean up.

yes, just yes.

In our organization, we primarily use sudo to avoid giving out the root password. We can easily reduce or revoke an individual's sudo privileges, but changing the root password is quite a bit harder since it entails letting all remaining privileged users know the new password, as well as changing it on every computer in the network.

Thus I elected to use sudo because it is familiar to us. Furthermore, I used sudo only for commands that require it, so it indicates which commands need write access beyond the confines of $HOME.

This particular Slackware guide isn't for teaching system administration or even producing a Slackware system for daily use. My guide exists to document the process by which I created a virtual machine appliance whose purpose is cross compilation targeting various platforms. Odds are good that no one will ever actually read the guide now that I have it written and the filesystem image produced, but nevertheless configuration management requires that I capture my processes rather than rely on a one-off blob whose assembly is undocumented and no one can reproduce.

That doesn't mean I'm okay cutting corners. It is my hope that someday we can branch out and use my guide as the basis for more Slackware systems, especially now that we're on the verge of getting sucked into Red Hat Enterprise Linux 7 and systemd.

Please don't let this thread devolve into Yet Another Systemd Discussion. I only mention it in passing because it is the highest profile reason why I leapt at the opportunity to use Slackware for this task rather than RHEL.

I agree it never made much sense to omit {,/usr}/sbin from regular user $PATH. As regular user I often query the network configuration. The only benefit I can think of is to limit tab completion to commands the user is likely to want, but that's such a weak argument it's more of a joke.

There exists an argument for leaving /sbin out of not only user $PATH but also root $PATH. That is: make root (or user having sudo) work a little bit harder to run potentially dangerous commands. The theory is that if you're forced to type "/sbin" you are acknowledging that you really do mean to run special system administration commands. I don't buy this argument. There's plenty of dangerous stuff in /bin, e.g. rm. It's not the commands that are privileged or dangerous but rather the operations they perform. For example, bash will happily zap a file without even forking (">/boot/vmlinuz").

The only way $PATH impacts security is when it contains relative paths, particularly "." or (even more insidious) empty string, in which case the current directory can cause the wrong command to get run.

I saw a refinement of this argument which is to give root an empty $PATH, to make root's life miserable, force all paths to be explicitly typed, and therefore prevent any accident. Of course I don't believe that will work. Here's the punchline: an "empty" $PATH actually contains empty string, meaning the current directory. This is both darkly hilarious and horrifyingly embarrassing.

So. Back to mkinitrd. In my opinion, not having /sbin on the depmod call is a regression. mkinitrd-1.4.5 in Slackware 13.1 said /sbin/depmod. Yet mkinitrd-1.4.6 in Slackware 13.37 said depmod with no /sbin.

3 members found this post helpful.

This makes plenty of sense and I'm glad to see you're using sudo as it was originally intended. Many times when we see people making guides with sudo, it's making sudo available for all programs for a user to mimic Ubuntu. It's not necessarily wrong to do that (I do it with my main user), but it isn't the standard Slackware set up and people should know what they're doing (that last bit wasn't directed at you, but just clarifying things in case anyone else was wondering what I was intending).

But short of modifying mkinitrd itself, you could make the changes in /etc/sudoers that I mentioned above to set a particular PATH to be used when using sudo. This will solve the issue for everyone that uses that system.

I had the same teacher on that subject.

I agree that in the case of shell environments, security is primarily through the user privileges and secondarily (or not at all) through the commands executed.

When I open a shell as root it's as though I'm in possession of a sharp knife/tool with few or no safety features. Knowledge/training is what keeps me from cutting myself or others. I didn't accidentally stumble into root privileges, I had to use the root password. Now get out of my way and let me use the sharp knife/tool to work. (I do see a role for sudo functions however.)

Although built-in safeguards can be helpful (or a pain in the ass), I don't believe that we should rely on them. I try to do the proper action as though the safeguard was not in place.

Rather than than rely on a particular shell environment to do the right thing I've learned to follow personal best practices when typing commands and running impromptu scripts.

A simple example of this is that I never type the command "su", I always type "/bin/su". I'm about to tell a computer program the root password. I want to be careful what program I'm giving the password to. I don't want it to be a Trojan horse.

I've seen where less knowledgeable (clueless) users find more bugs in software than the experts. The experts know what NOT to try while the new users don't know better and try combinations that a knowledgeable user or tester didn't.

In adding /sbin & /usr/sbin to a regular user's path we may see some interesting effects when daemons and utilities are executed as a regular user in unusual ways. Most likely not however, as the programs have probably been thoroughly abused.

1 members found this post helpful.