Archaic wrote: > And apparently your statement is also incorrect because ssh can > properly create ptys all day long with the proper permissions. So > apparently a closer look into both scenarios is warranted.
I didn't try ssh. But I did try xterm and expect (both of which use PTYs), and both failed. (Although maybe this is the difference: I did not simply comment out the rule in my udev.conf and reboot. I did a "chown 0:0 /dev/ptmx ; chmod 0660 /dev/ptmx" as root, then changed to my normal user, then ran xterm and expect. So if my understanding of the default owner:group and permissions is wrong, that would cause my results to be different than yours.) (Wait a minute... sshd runs as root. PTYs work for root. I was not entirely clear in my message -- I should have said "this change would break PTYs completely *for non-root users*"; sorry for the confusion.) But even if ssh works (because it runs as root), as Alexander said, "script" requires PTYs, and we all know the expect testsuites do. (I've noticed a lot of BLFS packages have changed to building and testing as a non-root user. Maybe that doesn't matter because it's BLFS -- but script definitely does matter.) >> If your printer supports PostScript natively, you can cat PS files >> to your printer device. > > But you cannot do that without explicitly assigning a non-root user > to the lp group. As it stands today, you're right. (But then, that's not "non-LFS software" either...) > LFS will not have that group in the future so it wouldn't make sense > to create a device with the same perms it would have by default. Oh, I see what you're saying. Yes, if the group is deleted, the rule might as well go. (From another of your posts in this thread:) Archaic wrote: > And now that I think about a previous post that referred to > cluttering of the /dev tree, the whole intention of devices is that > they are not referenced by name, but by major and minor. Inside the kernel, yes (the kernel decides which code to dispatch a device syscall to based on the type, major, and minor numbers). But userspace requires the files to be in a standard place, because userspace doesn't have any other way of calling into the kernel (other than opening the device file, that is). (Besides, isn't a future kernel still going to remove the static device number allocations and move to a model where register_chrdev (or whatever) dynamically assigns the device numbers?) My reason for bringing that up was partially aesthetic, and partially because Documentation/devices.txt explicitly shows subdirectories for a lot of devices. I believe that just because the user hasn't installed gpm yet (for instance), doesn't mean they should be seeing non-standard device locations for these devices. The original proposal was there to remove groups from LFS, and the more I think about it, the more I'm not sure that's a good idea anymore either (someone else has said this, too), mostly for that reason. I am starting to think that device files are part of the "kernel package", and as such, should be configured by LFS, since LFS installs the kernel. Gerard may disagree with this, obviously, and it sounds like he has in the past, so maybe it's a moot point anyway.
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
