> ---- As written by David Holland:
> > This mapping is maintained by MAKEDEV. Sort of. It's very easy for
> > MAKEDEV to be wrong or just out of date. It's also very easy to have
> > additional bogus devices lying around. The last Slackware I saw (which
> > is not the most recent) had a few dozen bogus entries in /dev that
> > didn't point to *any* device at all. What happens if you make an entry
> > called "null" in /dev that's (3,1) instead of (1,3)? Anything
> > accessing "/dev/null" actually trashes the first partition of the
> > first IDE disk. This is not a good situation.
> >
> > If the names in /dev are generated directly by the kernel, like /proc
> > is, this problem disappears.
>
> And what about links like /dev/cdrom, /dev/modem, and /dev/mouse?
I agree with the point about getting the numbers wrong, but in normal
use, you shouldn't need to go around making block special or character
special files.
If you did need to, for wahtever reason, then, IMHO, you just have to be
careful. There are lots of ways to trash a system, and whenever you're
dealing in these areas, it is the same.
Apart from the permissions problem, there is also the issue of symbolic
links for device mapping. I do use links to /dev/modem and /dev/mouse so
I don't have to alter my software setup whenever my hardware changes.
This isn't often - but it's a convenience thing for when I do. Being
*SYMBOLIC* links, this wouldn't be a problem, except that all my devices
are then not in the same directory.
What about this?? Why couldn't we use a /etc/devices file, similar to
/etc/services et al? Or perhaps a more efficient solution, two files,
one for permissions and one for link mapping. Then you could have a
virtual filesystem along the following lines :-
whenever a request is made to access a file in /dev (now a vfs),
if the user is not root, the /etc/device.permissions file is checked
whenever a request is made to a device name the kernel does not know,
the /etc/devices.links file is checked.
This setup could also allow you to safely enable and disable devices - as
in remove them from the /dev heirarchy. eg. I only have one scsi device,
so /dev/sdb, etc are irrelevant to me. I also don't have 15 partitions, etc.
When opening a device, if it doesn't have a /etc/devices.permissions
entry, it could be interpreted the same way as the special file not
existing - or the links could be checked.
Reading the /dev directory would simply read the devices files and
generate the requested information fromtheir contents.
I realize this ends up being very similar to the current setup - a
directory is just a file containing filename, inode pairs, but it does
give the kernel the responsibility of device naming - if that is what the
concensus is on this matter. The only other problem I see with this
proposal, though, is that under other Unices, special files could occur
anywhere. I'm not saying this is a good practice, but what about the
portability/compatibility issues?? In providing such security, there will
have to be some loss of flexibility...
Brett :)
-- ******************************************************************************* *** Brett Gersekowski *** Experience is directly- *** *** bgerseko@enterprise.powerup.com.au *** proportional to the amount *** *** e1135350@watt.lab.eesse.bee.qut.edu.au *** of equipment ruined. *** *** n1135350@student.fit.qut.edu.au *** *** *******************************************************************************