Hi there!

I'm on section 6.25 - GCC (host is Debian 10) and I'm hitting a permission issue on the make command:

This is my first time encountering the nobody user and controlling terminal so this is new for me. What I've tried:

a. As I understand it, /bin/false comes from coreutils (which is installed in the /tools/bin, but not in /bin yet). So if it has a permission error, is it trying to access /bin/false from the host? is that possible within the chroot environment or am i misunderstanding the error?

b. - results in the same error from the make command
- su nobody -> Cannot execute /bin/sh: Permission denied

c. - results in the same error from the make command
- su nobody -> Cannot execute tools/bin/sh: Permission denied

The instructions say that nobody should be an unprivileged user. So it seems as though I need to change permissions on some files here's what I have now:

/bin/sh does exist, as a link to bash, with permissions lrwxrwxrwx.
the permissions of su are -rwsr-xr-x
all commands in /bin are owned by root

maybe the best option is to start Ch6 over. however, even if I will do that, I'm still curious what is the expected behaviour? How does the root hand off the controlling terminal to nobody to execute this command?

I did the mounts and chroot commands as per the instructions at start of Ch6

Due to lack of response on this I've opted to restart chapter 6

after retracing my steps from the beginning of section II, i have hit the same error: su: Cannot drop the controlling terminal

The first time around, I typed out all the commands. This time however, I copy-pasted every command. All tests passed as per the instructions. I didn't do a reboot through the process and all mounts are done according to the instructions.

if I adjust the command to:
it returns: Cannot execute /bin/bash: Permission denied

the symbolic link of sh & bash link to /tools/bin/bash which has permissions of -rwxr-xr-x so I currently believe that is why the nobody user can't execute the command.

Is this the expected permission level for /tools/bin/bash?

UPDATE:
-------
After reviewing this thread
I rebooted and remounted as per instructions in 6.2.2 and 6.2.3 but no chage in the result. I'm not sure how to verify /dev/pts is correct but ls /dev/pts -l
yields

crw--w---- 1 hostuser tty 136, 0 Apr 12 17:57 0
crw--w---- 1 hostuser tty 136, 1 Apr 12 18:09 1
c--------- 1 root root 5, 2 Apr 12 16:18 ptmx

# tty
returns:
not a tty

Lots of people would like to help, but it can be needle-in-haystack to think of whatever random thing could be wrong on a LFS system.

I can tell you that the bash binary should be rwxr-xr-x (755), owned by root. No special permissions, it's executable for everyone.

You'd need root privileges for that command but it should work

I don't actually do the tests for gcc. I'd know soon enough after that point if my compiler is broken. I'd generally spend more time and effort on the unit tests for the builds than I would starting over or fixing it in the unlikely event that I stuffed something up. No, I don't "recommend" others going against the instructions, but there it is.

Note that the chown command is a pretty important step for the current working directory (where you are building gcc), recursively.

I wonder if this is debian host related. They made changes to the way su works (PAM configuration?) some time ago, you can't just su down to a user from root anymore without prompting for password. I don't do debian, I just saw people complaining about this. That would seriously annoy me, right out of the box.

I am sorry, but that's about all the suggestions I have.

Hi there!

Thank you for you suggestion on this. Your comment got me thinking as I'd been reading about that debian change also but not understanding what it meant in practical terms. So here's what I tried. I created a passwd for nobody user. This did not change the response when running the command from within chroot. When running the command outside of chroot however, the command proceeded. The command then failed for a number of other reasons that I assume is mainly caused by running with bad environment settings.


I having been discussing with the folks at lfs_support(opening thread here) and mentioned your suggestion. Here's one response it has received so far:

Even though the mount commands were copy-pasted, they are saying there is something strange about the mount of /dev/pts on my device

Still working at it...

Thanks again

1 members found this post helpful.

Hi there!

I recently came across the same error on Fedora32 aarch64, working through the development version of LFS. I didn't exactly do much investigation into it but managed to find a fix using the insight from this post.

I simply switched to the unprivileged account.

then

The test outputs are similar to the published results so far, it seems to be working just fine (still running though..).

Hope this helps!

Hey! I faced the same issue in gcc tests.

In my case the issue was with the $LFS directory permissions, they were 700. I failed to track why I have it, but solved the issue.

P.S. Sorry for the dead posting, but hope it will help future LFS users :)