"su -s /bin/bash ..." works everywhere except Slack

MQMan · 10-07-2007, 02:03 AM

This is a follow up to this thread, but I thought I'd post it here, as after some experimentation, it only fails to work on Slack.

I was trying to get daemon from /etc/rc.d/init.d/functions to work. Initially this failed, because it uses runuser, which isn't installed in Slack.

After firing up an old RH I have as a VMWare image, hoping to snag a copy of runuser, I found that this version of RH didn't use it. It used "su -s /bin/bash ..." instead. Great, I thought, even easier. Except it doesn't work in Slack.

As an experiment, I tried the following in a number of distributions, running as root:

su -s /bin/bash - <user> -c 'ls -l ~'

Obviously using a valid <user>. I tried both users that were set up to be able to login, and also users that were setup with various variations of "/sbin/nologin", and similar.

On RH, Ubuntu live CD, and Knoppix live CD, this worked every time.

However, on Slack, all it does is load a 2nd copy of the shell, and doesn't switch user, or execute the command.

Why is Slack different, and how can I get it to behave like other distros.

Cheers.

macemoneta · 10-07-2007, 04:01 AM

Are they the same version? For example:

Code:

$ su --version
su (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

uselpa · 10-07-2007, 04:41 AM

This works fine for me:

Code:

su - <user> -c "/bin/bash -c ls -l ~"

uselpa · 10-07-2007, 04:43 AM

or even (since bash is the default shell)

Code:

su - <user> -c ls -l ~

MQMan · 10-07-2007, 01:41 PM

Quote:

Originally Posted by uselpa

This works fine for me:

Code:

su - <user> -c "/bin/bash -c ls -l ~"

Great, thanks. But that's a strange syntax, and not the one that's supposed to work. I'd still like to know why Slack is treating this differently than the other distros.

Quote:

Originally Posted by uselpa

or even (since bash is the default shell)

Except I want to run a program as a user who doesn't have a default shell. Which gives me this:

Code:

root@The-Tardis:~# su - slimserver -c '/bin/bash -c ls -l ~'
No shell

So, that trick still doesn't do what I need.

And this is the version I get on Slack:

Code:

root@The-Tardis:~# su --version
GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

Which looks like the bash version, not su.

Sorry, should have mentioned this is Slack 12. I just noticed my profile is out of date.

Cheers.

uselpa · 10-07-2007, 02:45 PM

--version is not an known argument to su, so it fowards it to bash, which accepts --version and acts accordingly.

In Slackware 12, /bin/su is part of the shadow-4.0.3-i486-14 package.

As for a user without a default shell, I assume you have set it to /bin/false? Indeed that doesn't seem to work. Why is that a requirement?

MQMan · 10-07-2007, 05:33 PM

Quote:

Originally Posted by uselpa

--version is not an known argument to su, so it fowards it to bash, which accepts --version and acts accordingly.

So why did it work for macemoneta above. Plus, it works in my VMWare version of RH.

Quote:

Originally Posted by uselpa

In Slackware 12, /bin/su is part of the shadow-4.0.3-i486-14 package.

Yeah, and looking at the slackbuild scipt, I can't see any "odd" directives that might make it work like this.

Hmmmmm. But, I also noticed that for other systems, it's part of coreutils. Maybe a completely different version. I'll check that later, as I don't have time now.

Quote:

Originally Posted by uselpa

As for a user without a default shell, I assume you have set it to /bin/false? Indeed that doesn't seem to work. Why is that a requirement?

That particular user is set up with /sbin/nologin. I also tried a user that was set up as /bin/false. Still launched a 2nd shell.

It's the way that slimserver installs itself, to allow it to run under it's own account, but not let anyone log in. When I first hit this issue, and stated Googling around, I found it was used like this for a number of packages.

Cheers.

arcanex · 10-08-2007, 03:33 AM

I just tried 'su --version' and it didn't work (I got bash's version instead). I am running Slack 10.2 btw.

So it would seem like the version of 'su' that Slackware ships with is not the same as the one in GNU coreutils. I don't know why the GNU 'su' doesn't ship with the Slackware coreutils package, but if you need the '-s' option in Slackware (I use it myself in some RHEL scripts), you're probably gonna need to get the GNU version of 'su', as the one in Slackware doesn't support it.