Hi

I've installed most of the packages in Chapter 6 using the package user. Everything was going fine but when I got to the 45th package I received the message -

setgid: operation not permitted

when it was trying to put me into the install directory for the package.

This implies I am no longer running as root but as far as I can tell I am still chrooted into the lfs environment.

What could be causing this message? I am sure the answer is simple but I am stumped for the moment.

Too many ./configure&&make&&make installs addles the brain!

LFS 6.1 - Chapter 6 - 6.45.1. Installation of GRUB

Is this the package you are refering to?

Please be more specific

I am not talking about a specific package. I am referring to the package user command

install_package foo foo foo

up to sysklogd everything was fine. When I tried to install sysklogd I got the setgid problem.

It seems as though PATH now needs /sbin because I added this and it works again. Very strange. I don't quite understand what happened, but with this revised PATH description I can continue the install

setgid problems happen when your user doesn't have permission to make a change to a directory or file. It would be interesting to know how you suddenly lost those permissions.

The last package I installed before the setgid problem was shadow. Shadow installs useradd and groupadd. I think this is where the problem lies because before shadow these two routines were taken from /tools/bin.

This is why I had to change the PATH to include /usr/sbin, the location for the new useradd and groupadd routines.

I suspect this is because su likes to be run as root with the suid bit set. Maybe try something like this:

ls -l /bin/su

Since you're using Matthias S. Benkmann's insightful "Package Users" hint, su is probably owned by 'shadow' or whatever the "package user" is named. If so, perhaps something like this will help:

chown root:shadow /bin/su
chmod 4755 /bin/su
ls -l /bin/su

Cheers,
-Eric



git://freesa.org/package-users

1 members found this post helpful.

So what does your PATH now look like for a package user?

The PATH is no different than a normal LFS build. While still depending upon the tools directory it will look something like:


/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin:/tools/sbin


Later when going "Beyond" it might look something like:


/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin


So I wouldn't expect most people to experience PATH issues.

The first big difference one might notice is that when installing packages as a non-root user, one package can not overwrite the files of another package.

Another difference is that "make install" won't create programs that are setuid root. Matthias S. Benkmann's original "LFS Hint" describes why this is good (basically that we want to make that kind of decision very intentionally) and provides some ideas which might be useful when making those decisions for your own system.

A third difference is that ls becomes an "information radiator"; since files all belong to the package which owns them, I'm regularly reminded of which files belong to which packages:


-rwxr-xr-x 1 kbd kbd 120291 Mar 4 22:38 loadkeys
-rwxr-xr-x 1 util-linux-ng util-linux-ng 18350 Feb 24 19:10 logger
-rwxr-xr-x 1 shadow shadow 78772 Mar 5 20:20 login
-rwxr-xr-x 1 coreutils coreutils 124122 Feb 24 20:18 ls
-rwxr-xr-x 1 module-tools module-tools 12242 Mar 5 20:01 lsmod
-rwxr-xr-x 1 coreutils coreutils 57098 Feb 24 20:18 mkdir


This approach to package management isn't for everyone, but I'm quite pleased with it, and I feel I've learned some things along the way that I may not have otherwise.

Cheers,
-Eric


Matthias S. Benkmann's hint may be found here:

http://www.linuxfromscratch.org/hint...nd_pkg_man.txt

I use slightly modified versions of the scripts:

http://www.freesa.org/projects/show/package-users

Hi EricHerman,

thnaks for the reply, but I already have my LFS working with package users. I only wanted to check if the OP has the path to the install-wrappers as first path for the package user in his PATH variable. And if you follow the recommendation in the README your install wrappers should reside in /usr/lib/pkgusr. This should be the first directory in your PATH.

Only if your PATH is setup to use the install-wrappers first.

Anyway I do recall running into similiar trouble as the OP after installing shadow. However, I did not make su suid root. I even kept the owner shadow. I do not want normal users to 'su'. If users do not have multiple accounts 'su' is not necessary for them anyway. In fact it poses even a security risc if they were able to su into a package user due to some faulty configuration issues.

Crts, you're quite right. A tiny experiment shows that my memory is weak:

root:/# su - shadow
package shadow:/usr/src/shadow> echo $PATH
/usr/lib/pkgusr:/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin


Further, you're absolutely right to be asking about the path, as the chmod wrapper would normally prevent a "chmod 4755" ... which would otherwise result in a file not being 4755 as root but rather as the package user.

However, a quick reinstall of shadow shows something interesting:


package shadow:/usr/src/shadow> ls -l /bin/su
-rwsr-xr-x 1 shadow shadow 66107 Mar 7 10:13 /bin/su


A look at what make install does, and we find it uses a -f parameter to chmod to suppress most error messages:


package shadow:/usr/src/shadow> grep -C1 "chmod -f" 03-install.log
for i in su; do \
chmod -f 4755 /bin/$i; \
done
for i in chage chfn chsh expiry gpasswd newgrp passwd; do \
chmod -f 4755 /usr/bin/$i; \
done
package shadow:/usr/src/shadow>


So ... what does the -f do with our chmod wrapper? Well let's see:


package shadow:/usr/src/shadow> touch foo
package shadow:/usr/src/shadow> chmod 4755 foo
*** chmod 4755 foo
package shadow:/usr/src/shadow> ls -l foo
-rwxr-xr-x 1 shadow shadow 0 Mar 7 10:18 foo
package shadow:/usr/src/shadow> chmod -f 4755 foo
package shadow:/usr/src/shadow> ls -l foo
-rwsr-xr-x 1 shadow shadow 0 Mar 7 10:18 foo
package shadow:/usr/src/shadow>


This appears to be how, even with the wrappers in place, we see a /bin/su which is suid 'shadow'.

A quick fix is to chmod 4777 them as root (if you want them to be suid root), or simply add this to the install procedure:


for i in su; do \
chmod 755 /bin/$i; \
done
for i in chage chfn chsh expiry gpasswd newgrp passwd; do \
chmod 755 /usr/bin/$i; \
done



But better would be to fix the script.

Let's look at what the wrapper does and see why it fails:


case "$1" in
g+s|u+s) report=1; doit=0 ;;
4755) shift 1 ; set -- 755 "$@" ; report=1; doit=1 ;;
4555) shift 1 ; set -- 555 "$@" ; report=1; doit=1 ;;
*) ;;
esac


And we have our answer: the script looks for the permissions to be in the fist place, and doesn't account for any other parameters to be in position $1.

Okay, so this shouldn't be too hard to deal with, should it? Rather than checking for "$1" perhaps it should loop over the arguments? Perhaps this evening I will make time to try that.

Cheers,
-Eric

You're right. I should also change this in my wrappers some time. Since I automatised the base installation of my LFS, I dealt with this issue by just having my base install script to remove the suid flag. As I already said, 'su' is not needed for normal users on my system.
When I was debugging I noticed that the order of the parameters for install is critical. But I have not bothered 'correcting' that. I am not sure about the side-effects. Right now I do not have the time to fix it. Making some minor changes to the install_package script - necessary for the automation - yielded some unexpected results. Right now, I am happy that it is working, even though I am still not 100% satisfied with it.