I have to jump through four login prompts, a modem, and _two_ firewalls
to get to my email (one to get out of where I am and another to get into
where I used to be and where my email still goes)...we're waiting for
ISDN here so we can cut it down to just one firewall, Kerberos tickets
instead of login prompts, and zero modems. Getting mail is an adventure
in the mornings. :)
> > One solution is to create an rc.dev file that runs MAKEDEV at boot time.
> > For standardization purposes, it should be a part of the kernel sources or
> > distributed through the current kernel distribution channels (Hi, Linus!).
> > Ditto, IMHO, for everything else that only configures Linux-specific
> > things, like setserial, tunelp, ifconfig/route/netstat, kbd (which is
> > already distributed this way), hdparm, setfdprm, fdformat, cdtester
> > (buried in drivers/block), and other fun tools that keep getting out
> > of date. This way, everybody gets one standard up-to-date MAKEDEV every
> > 4.3 days or so (depending on how fast Linus is that week ;-).
>
> Yes, but I am particularly thinking of devices not distributed with
> the kernel. I am one person working on the Linux-Lab project. There
> are potentially a very large number of device drivers for cards used
> for instrumentation and laboratory control (GPIB, ADC, DAC,
> counter/timers, DIO, stepper motor, optical encoders, etc, etc..). I
> would like it if the drivers automatically created device entries
> when they are loaded (usually as modules).
Hmmm...someone proposed that /proc/dev/* should contain a stub dev
directory, with all the right major/minors and names, so you have a
script in /etc/rc.d/rc.dev that does 'cp -af /proc/dev /' then a lot of
ch{mod,own}s, and finally some extra shell goo to get rid of dead
device entries (which is probably the most important part, especially
if permissions are a problem and device majors are dynamically assigned).
I'd agree with that proposal, provided that you couldn't actually open
/proc/dev/* with _any_ privileges (just in case someone manages to
force a read or write as root but can't get further access--e.g. via
ftp or somesuch) and/or all /proc/dev entries are mode 0 in /proc/dev.
The /etc/rc.d/rc.dev script can set ownership and permissions once the
files are copied to /dev; there's no need to add the bulk of supporting
owner/group/mode in the kernel. The device names could either be in a
table or preferably computed on the fly with a table of functions that
create a set of device names and minors for each major.
insmod could call an auxiliary rc.dev script for each inserted module
to set up its dev entry. There's no need for the kernel to do this.
> > > The /proc filesystem could be extended to support symlinks, and
> > > preserved across reboots with the above mentioned config file.
> >
> > For those who are considering kernel solutions, bear in mind that I
> > won't run a /dev that doesn't support multiple mount points, no implicit
> > insertion of entries, and permanent explicit removal of entries.
> >
> > We have a secure Linux box upstairs that puts every user into their
> > very own private chroot environment, complete with its own private /dev
> > entries. /dev/fd0 had better _not_ appear automatically when
> > you insert a floppy/insmod the floppy driver, or other "cute" things
> > like that. That would be a really Bad Thing.
>
> I agree wholeheartedly, BUT would it be a bad thing if /proc/dev/fd*
> appears automatically when you load the floppy module and disappears
> when you unload it?
No...well, not really.../proc isn't mounted wherever I _really_ care about
internal security on the machine, so things appearing in it would just
cost kernel overhead.
> > Personally, I'd prefer to move things from /proc to /dev. It would
> > allow us to un-setuid things like pppd (which could be setgid instead).
>
> I'm not sure I understand this, but I presume you are talking about
> requiring root permissions to access some /proc entries. If /proc
> supports changing file modes and owners you can still do this with
> /proc/dev.
Never mind, I checked and discovered that when I wrote that paragraph
I didn't know what I was talking about. I was under the impression
that ifconfig did open(/proc/something) then ioctl calls on it, when in
reality it does socket(PF_INET, SOCK_DGRAM, IPPROTO_IP).