Pure LFS coreutils - I rest my case (temporarily :)
Bill's LFS Login
lfsbill at wlmcs.com
Thu Apr 24 15:28:40 PDT 2003
Good explanation you've given. It does leave me with some questions
On Thu, 24 Apr 2003, Erik-Jan wrote:
> Bill's LFS Login wrote:
> > You folks are a tough audience!
> Hehehe :))
> But I think I've found why you're having such a hard time with the
> fail-2eperm-test. It all has to do with versions of su. Both
> coreutils/shellutils and shadow have a su. There are some differences
> between these versions.
I do have shadow installed. I suppose that should be standard?
> Shadow-su (which apparently is installed on your system) wants "username
> args" in that order, coreutils-su doesn't care which comes first. If
That 'splains whay my man version shows username first, I guess. And I
bet it has been more than 10 years since I habitually worked on a system
that didn't have shadow passwords.
> shadow-su is invoked like this: "su -c "command" username, it just
> forgets about the username. It runs the command with the permissions of
> the user that issued the su, in this case root. That's why your tests
> d-g all remove a/b, the rm-command is executed as root.
Yep, that was my guess after testing it all out.
> Coreutils-su executes the command as user, no difference if the user
> is before or after the -c.
> Coreutils-su on the other hand, seems to have a problem calling bash,
> because it takes BASH_ENV from root. This gives the error
> "/root/.bashrc: Permission denied", because the non-root-user doesn't
> have permissions in /root. Shadow-su clears BASH_ENV, so no problems
He-he! Fertile ground for SUS developemnt, I think.
> All this leads to one conclusion: the fail-2eperm-test should be run
> using the newly-built coreutils-su. This prevents su-issues from the
> hosts creeping up in the test. So, using /bin/su in the test really
> isn't ok.
I would disagree for one reason, with a wuestion. At the time, has the
new su been tested? If not, what if it is broken and then causes the
fail-2eprm test to fail. OTOH, if /bin/su is called from a production
host, and the new name is put first, and your BASH_ENV issue is
addressed, I think we have the greatest chance of success.
This presumes that all versions of su accept the logname in the first
position (is that a safe assumption?) and all parameters found after the
logname are to be passed to the new shell. And we can apply your fix for
the BASH_ENV issue.
> Preventing the BASH_ENV doing ugly things can be done with adding
> --shell=/bin/sh (or -s /bin/sh if you don't like to type :)) to the
Is this only good for the coreutils version? I suspect we will find it
is not universal? Additionally, can't we do something like
/bin/su $name -c '/bin/sh ....'
or possibly use the env in there like Ryan had in one of his su calls to
do the same job? I looking for a way that works regardless of su version
and doesn't depend on the (as yet untested?) coreutils.
Last, does this have any potential pitfalls if we are upgrading glibc?
> I'll see what I can do to src/su.c, to make it clean BASH_ENV. Most
> likely I will just make it crash, I don't know much about c...
I have some experience in C if you experience difficulty. Feel free to
post me (off list would be best, I guess).
> Secondly, there should be a test (like Ryan's) to check if the shell
> indicated in /etc/passwd really can execute commands. Users like your
> user mysql should never be allowed to do shell-things, otherwise they
> wouldn't have /bin/false as shell.
In my final version, you'll see in the big logs that mysql didn't do
anything. Several were skipped and the test automativcally selected user
'nobody', which is really what Ryan was shotting for anyway. So, it
looked pretty good to me (keeping in mind I have some degree of
ignorance on these things).
> I've finished a test-build with a patched fail-2eperm-test, just like I
> suggested in an earlier post. It all went OK, both in ch5 and ch6. For
> completeness, I've attached the patch I used. It is made for
> coreutils-5.0, but also works on versions 4.5.10 and up.
> For versions 4.5.9 and earlier, there isn't a valid-shell test, so the
> patch doesn't apply. Just adding -s /bin/sh to the su should make the
> test work in these cases.
I'll give your change a shot when this current build finishes (should be
BTW, is your password file carrying the encrypted passwords? This is
supposed to be less secure than the shadow password schema, IIRC. I
wonder if the coreutils install will wipe out the su from shadow, and if
so, will I be screwed?
lfsbill at wlmcs.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev