This is a semi-random collection of posts on nearly all things Slackware and Linux-related -- at least as I see it.
Build Notes for LFS 6.6 with Package Users -- Part 3
Continued from part 2.
Shadow-4.1.4.2
Installation fails as indicated in the hint because of the international man pages. I decided to install them. After the installation failure: Change the foreign language man page directories to install groups as the root user, from /usr/share/man:
and
Finally, I chose to set su, chage, chfn, chsh, expiry, gpasswd, newgrp and passwd as setuid root.
Additional notes from crts:
After finishing the installation logout and configure shadow as root.
Fix the permissions for passwd:
By default /bin/su got permission 4755 but with user:group set to shadow:shadow. This prohibits roots from using su. Fix permission for su with
If you want normal users to be able to use su then apply following changes
Keep in mind that other binaries of this package might need permission adjustment, too, e. g. useradd, groupadd, etc.
Apply additional 'sed' to avoid future complains about non-existent default group:
Sysklogd-1.5
From the hint: "sysklogd's Makefile has /usr/bin/install hardwired as the install program, which circumvents the install wrapper. The wrapper is needed for sysklogd because it tries to make its manpages owned by root (which obviously a package user is not allowed to do). Therefore, install with 'make INSTALL=install install'."
Sysvinit-2.86
Do not follow the instructions in the package user hint. They are no longer applicable, probably because the items in /dev are bind mounted to the host. Nothing special was needed for a package user.
Tar-1.22
Nothing special as a package user.
Texinfo-4.13a
Nothing special for a package user to install the package.
crts recommends:
After installation recreate the file /usr/share/info/dir as user root. The best option here is to store the following commands in a script since recreation of /usr/share/info/dir might be necessary in the future. Choose an appropriate place and name for the script.
Udev-151
Nothing special for a package user. The hint seems to be out of date.
crts recommends executing the following command as root:
Vim-7.2
I did not build Vim, but nobody has reported any special steps necessary to build it as a package user.
Nano-2.2.5
Emacs-23.2
I installed two extra packages, Nano-2.2.5 and Emacs 23.2. Nothing special was needed for Nano.
The old canard about Emacs being a wonderful operating system with a mediocre text editor is (sadly) somewhat true. LFS with just Emacs installed from BLFS is a surprisingly capable system with a built-in file manager, a good development environment, and even some games.
Anyway, the Emacs-23.2 installation initially fails because /var/games needs to be created and made into an install group.
Chapter 7.2 LFS-boot scripts
No problems when built as a package user.
Chapter 8.3 the Linux kernel
There are no problems configuring and building the Linux kernel as a package user. When trying to copy the compiled kernel image to /boot a permission denied error will occur because /boot is not an install directory.
I copied the files manually to /boot as the root user. crts made /boot an install directory.
Chapter 8.4: GRUB
I use my host’s installation of LILO to boot LFS. If using Grub, crts recommends that all the steps in this chapter should be performed as root. Creating a rescue floppy is optional. Manually edit /boot/grub/grub.cfg. You will most probably have to change entries like /dev/hda1 to /dev/sda1. Also edit the /etc/fstab accordingly.
V. Conclusion
At first blush, the above notes seem complicated. Building a system with package management is more complicated than building it without. But maintaining the system is a lot easier with package management, so I feel the trade-off is worth it.
More to the point, using package users gets easier after the first couple of builds. The first couple of builds are also some of the trickiest, so the above notes should help get new package user users over the hump.
What remains to be seen is how well the package user scheme works for building X and the various applications from Beyond Linux from Scratch.
--------------------------------------------------------
Explanation of devpts Mounting
The full message is available on the lfs-dev mailing list:
Bryan Kadzban bryan at kadzban.is-a-geek.net Sat Oct 9 20:50:46 MDT 2010
Look in the kernel sources. See fs/devpts/inode.c, around line 494 (in 2.6.35.5), function devpts_pty_new. After creating an inode struct for the slave device, and setting its inode index to the slave device's number, the code does this:
inode->i_uid = opts->setuid ? opts->uid : current_fsuid();
inode->i_gid = opts->setgid ? opts->gid : current_fsgid();
/* <set {i,a,m}time to right now> */
init_special_inode(inode, S_IFCHR|opts->mode, device);
The opts->* fields are set by mount options; if you pass uid=x when mounting devpts, then opts->setuid will be 1, and opts->uid will be x. Same with gid=x and the *gid fields, and same with ->mode (which defaults to 0600 if not provided in the mount options).
And of course, current_fsuid() and current_fsgid() are accessors for the filesystem UID and GID of the current process (i.e. the one that called open() on /dev/ptmx, since that handler calls into here).
So, first: When you mount devpts inside the chroot, are you giving it a uid=xxxx parameter? If so, don't.
The kernel does all the work for you. As long as a user exists, and the fsuid/fsgid are set properly, you have permission, and grantpt() should be doing exactly nothing.
I suspect that if there's a problem [with the ‘expect -c "spawn ls"’ test run as a non-root user] it's with glibc. I'm pulling down 2.12.1 now, to see what I can find out about the implementation of grantpt()...
OK, I've looked at grantpt (sysdeps/unix/grantpt.c FWIW). It appears to be trying to verify several things on the pty slave:
- Is its UID the same as the current user?
- Is its GID that of the "tty" group (if that exists) or the current user (otherwise)?
- Is its mode 0620?
If any of those fail, it will attempt to fix the problem (which will only work as root), and fork out to pt_chown if it can't. So, second, you *have* to be sure the GID of slaves is tty, and the mode is 0620.
And, remember the mount options above? This is where they come in. :-) You'll need to ensure you use gid=4,mode=0620 (assuming you set up /etc/group the way the book does). But I'm seeing that section 6.2 is wrong; it isn't specifying either a mode or a gid for the devpts mount. That should probably change to:
to make this work properly.
Shadow-4.1.4.2
Installation fails as indicated in the hint because of the international man pages. I decided to install them. After the installation failure: Change the foreign language man page directories to install groups as the root user, from /usr/share/man:
Code:
find /usr/share/man -type d -exec chgrp install '{}' \;
Code:
find /usr/share/man -type d -exec chmod g+w,o+t '{}' \;
Additional notes from crts:
After finishing the installation logout and configure shadow as root.
Fix the permissions for passwd:
Code:
chown 0 /bin/passwd chmod 4765 /bin/passwd
Code:
chmod 0755 /bin/su
Code:
chown 0 /bin/su chmod 4755 /bin/su
Apply additional 'sed' to avoid future complains about non-existent default group:
Code:
sed -i '/GROUP/d' /etc/default/useradd
From the hint: "sysklogd's Makefile has /usr/bin/install hardwired as the install program, which circumvents the install wrapper. The wrapper is needed for sysklogd because it tries to make its manpages owned by root (which obviously a package user is not allowed to do). Therefore, install with 'make INSTALL=install install'."
Sysvinit-2.86
Do not follow the instructions in the package user hint. They are no longer applicable, probably because the items in /dev are bind mounted to the host. Nothing special was needed for a package user.
Tar-1.22
Nothing special as a package user.
Texinfo-4.13a
Nothing special for a package user to install the package.
crts recommends:
After installation recreate the file /usr/share/info/dir as user root. The best option here is to store the following commands in a script since recreation of /usr/share/info/dir might be necessary in the future. Choose an appropriate place and name for the script.
Code:
#!/bin/bash # /usr/sbin/recreate-info-dir rm -vf /usr/share/info/dir for file in /usr/share/info/*; do install-info "$file" /usr/share/info/dir 2>/dev/null done chown 0:install /usr/info/dir chmod 664 /usr/info/dir
Nothing special for a package user. The hint seems to be out of date.
crts recommends executing the following command as root:
Code:
mknod -m0666 /lib/udev/devices/null c 1 3
I did not build Vim, but nobody has reported any special steps necessary to build it as a package user.
Nano-2.2.5
Emacs-23.2
I installed two extra packages, Nano-2.2.5 and Emacs 23.2. Nothing special was needed for Nano.
The old canard about Emacs being a wonderful operating system with a mediocre text editor is (sadly) somewhat true. LFS with just Emacs installed from BLFS is a surprisingly capable system with a built-in file manager, a good development environment, and even some games.
Anyway, the Emacs-23.2 installation initially fails because /var/games needs to be created and made into an install group.
Chapter 7.2 LFS-boot scripts
No problems when built as a package user.
Chapter 8.3 the Linux kernel
There are no problems configuring and building the Linux kernel as a package user. When trying to copy the compiled kernel image to /boot a permission denied error will occur because /boot is not an install directory.
I copied the files manually to /boot as the root user. crts made /boot an install directory.
Chapter 8.4: GRUB
I use my host’s installation of LILO to boot LFS. If using Grub, crts recommends that all the steps in this chapter should be performed as root. Creating a rescue floppy is optional. Manually edit /boot/grub/grub.cfg. You will most probably have to change entries like /dev/hda1 to /dev/sda1. Also edit the /etc/fstab accordingly.
V. Conclusion
At first blush, the above notes seem complicated. Building a system with package management is more complicated than building it without. But maintaining the system is a lot easier with package management, so I feel the trade-off is worth it.
More to the point, using package users gets easier after the first couple of builds. The first couple of builds are also some of the trickiest, so the above notes should help get new package user users over the hump.
What remains to be seen is how well the package user scheme works for building X and the various applications from Beyond Linux from Scratch.
--------------------------------------------------------
Explanation of devpts Mounting
The full message is available on the lfs-dev mailing list:
Bryan Kadzban bryan at kadzban.is-a-geek.net Sat Oct 9 20:50:46 MDT 2010
Look in the kernel sources. See fs/devpts/inode.c, around line 494 (in 2.6.35.5), function devpts_pty_new. After creating an inode struct for the slave device, and setting its inode index to the slave device's number, the code does this:
inode->i_uid = opts->setuid ? opts->uid : current_fsuid();
inode->i_gid = opts->setgid ? opts->gid : current_fsgid();
/* <set {i,a,m}time to right now> */
init_special_inode(inode, S_IFCHR|opts->mode, device);
The opts->* fields are set by mount options; if you pass uid=x when mounting devpts, then opts->setuid will be 1, and opts->uid will be x. Same with gid=x and the *gid fields, and same with ->mode (which defaults to 0600 if not provided in the mount options).
And of course, current_fsuid() and current_fsgid() are accessors for the filesystem UID and GID of the current process (i.e. the one that called open() on /dev/ptmx, since that handler calls into here).
So, first: When you mount devpts inside the chroot, are you giving it a uid=xxxx parameter? If so, don't.
The kernel does all the work for you. As long as a user exists, and the fsuid/fsgid are set properly, you have permission, and grantpt() should be doing exactly nothing.
I suspect that if there's a problem [with the ‘expect -c "spawn ls"’ test run as a non-root user] it's with glibc. I'm pulling down 2.12.1 now, to see what I can find out about the implementation of grantpt()...
OK, I've looked at grantpt (sysdeps/unix/grantpt.c FWIW). It appears to be trying to verify several things on the pty slave:
- Is its UID the same as the current user?
- Is its GID that of the "tty" group (if that exists) or the current user (otherwise)?
- Is its mode 0620?
If any of those fail, it will attempt to fix the problem (which will only work as root), and fork out to pt_chown if it can't. So, second, you *have* to be sure the GID of slaves is tty, and the mode is 0620.
And, remember the mount options above? This is where they come in. :-) You'll need to ensure you use gid=4,mode=0620 (assuming you set up /etc/group the way the book does). But I'm seeing that section 6.2 is wrong; it isn't specifying either a mode or a gid for the devpts mount. That should probably change to:
Code:
mount -vt devpts -o gid=4,mode=0620 devpts $LFS/dev/pts
Total Comments 0
