Drew Ames wrote: > What you say is true for the root user, Nope, it's true for the non-root user that I run as, every day, as well. Every time I start urxvt or xterm, in fact. My pt_chowns -- both of them, since this is a multilib system and each bit-size glibc installed its own -- are user:group glibc:glibc, mode 0755.
No problems with either expect, or terminal emulators.
> Please see the thread started by Juan Carmona, "expect -c "spawn ls"
> command using Package Users hint," starting on August 17, 2010.
I haven't seen that thread -- but I'd rather 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.
> There's something about working as a non-root user that causes a
> problem. I suspect it's because, at least until one builds and
> install shadow, the copies of useradd and groupadd used by the
> package user scripts aren't very sophisticated (see section 5.10
> Temporary Files in the hint).
They're not sophisticated, but they're also not relevant here. 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.
FWIW I suspect that if there's a problem (I haven't seen this thread you
mention), it's with glibc. 2.10.1 works fine for me, but that's old;
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:
mount -vt devpts -o gid=4,mode=0620 devpts $LFS/dev/pts
to make this work properly.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
