> And it works for no devfs _without_ touching any /etc/rc.d files at
> all. Why do work when none is enough?
why make and run scripts when no work is needed
> OK, agree on a standard then. UUIDs work with IDE, SCSI, ... for disks. OK,
> done. Network doesn't need /dev entries. DOne too. Sound needs different
uuids work for non-removable media. if i change my zip cart, it'll have a different
uuid. uuid isn't an encompassing solution.
> Maybe. What is questioned is that it may very well not be the best solution
> in many cases, and isn't by far in the cases bandied around here.
so far, it is the only solution that has been accomplished other than bad mouthing
it because some people don't like it. if it isn't perfect we work on it. linux
isn't perfect but we improve it constantly. should we delete linux because it isn't
the best solution?
> "rm /dev/hda5" doesn't work; neither does "chmod g-w /dev/fd0".
# ls -l /dev/fd0
brw-rw---- 1 root root 2, 0 Dec 31 1969 /dev/fd0
# chgrp users /dev/fd0
# ls -l /dev/fd0
brw-rw---- 1 root users 2, 0 Dec 31 1969 /dev/fd0
$ dd if=/dev/zero of=/dev/fd0
649+0 records in
648+0 records out
# chmod g-w /dev/fd0
# ls -l /dev/fd0
brw-r----- 1 root users 2, 0 Dec 31 1969 /dev/fd0
$ dd if=/dev/zero of=/dev/fd0
dd: /dev/fd0: Permission denied
# rm /dev/fd0
# ls -l /dev/fd0
ls: /dev/fd0: No such file or directory
# mknod -m 660 /dev/fd0 b 2 0
# ls -l /dev/fd0
brw-rw---- 1 root root 2, 0 Oct 9 14:01 /dev/fd0
# dd if=/dev/zero of=/dev/fd0
109+0 records in
108+0 records out
seems like a fair lack of excitement here. or was it supposed to do something
strange?
# ls -l /dev/h*
brw------- 1 root root 3, 2 Oct 1 21:54 /dev/hda2
brw------- 1 root root 22, 0 Dec 31 1969 /dev/hdc
brw------- 1 root root 22, 64 Dec 31 1969 /dev/hdd
brw------- 1 root root 22, 65 Dec 31 1969 /dev/hdd1
# rm /dev/hdc
# ls -l /dev/h*
brw------- 1 root root 3, 2 Oct 1 21:54 /dev/hda2
brw------- 1 root root 22, 64 Dec 31 1969 /dev/hdd
brw------- 1 root root 22, 65 Dec 31 1969 /dev/hdd1
# mknod -m 600 /dev/hdc b 22 0
# ls -l /dev/h*
brw------- 1 root root 3, 2 Oct 1 21:54 /dev/hda2
brw------- 1 root root 22, 0 Oct 9 14:05 /dev/hdc
brw------- 1 root root 22, 64 Dec 31 1969 /dev/hdd
brw------- 1 root root 22, 65 Dec 31 1969 /dev/hdd1
hmmm. perhaps i'm missing something.
> OK, how many _different_ kinds of devices do you plug into it?
take a lab with lots of laptops, lots of portable things that plug into either
laptop or desktop, you know, disks, mice, modems, etc, multiply that by the number
of people walking around.
even that it happens for just one device for just one person in that office for just
a few times that day, that's why "hotswap" is so convenient.
should we have the NT version of pcmcia or the hotswap version?
> Again, how many _different_ kinds of devices will I be using simultaneously
> on it? What kind of iBook devices plug themselves in, just by themselves,
> and get instantly useable without any user intervention?
i take my favorite usb mouse with me because it's the only one i have with a wheel.
i plug it in and go, NO changes needed in the already running X system. i can
unplug it and use the glidepoint in the keyboard if i don't have my mouse with me.
i don't want to have to run scripts to reset everything every time i change
something.
it's called "user friendly" not "this is unix so it'll work but you have to do
everything before i'll let it work"
> > > - Impact on security: What if the permission handling machinery goes
> > > missing or breaks? What new kinds of attacks does this make possible?
> > > Ways to fix them?
what if update goes missing or breaks, what if what if what if. what if the cpu
goes missing or breaks.
that's as logical as saying what if the password file disappears so we shouldn't use
a password system.
> > Seems to fail safe to me, failure or non-use of permission handling
> > machinery would result in default permissions. These tend to be
> > _more_secure_ than modified permissions.
>
> All devices 000 by default? What is "paranoid secure permissions" for you
> might be "criminal insecurity" for the next guy.
that devfs is a bloated mess to you is a beautiful convenience for the next guy.
> > > - Impact on administration: "For Linux, unlike any other Unix system,
> > > devices are managed by...". This hinders people portability.
nothing has changed in the unix way i manage devices other than i spend less time
doing it.
> All of them handle them as files that have persistent permissions, AFAIK.
all of this talk about permissions and we skirt over the fact that tty permissions
change for every use. nothing persistent there, all managed dynamically and by
policy, by the devices accessing them.
> > > - Impact on software portability: What if this cool foo package needs to
> > > change permissions on the bar device? On installation? During operation?
>
> > It does so. Just expect a consistent set of permissions at boot time.
>
> Useless, if I need it at boot.
it is not beyond the intelligence of this community to design a persistent structure
available at boot time.
> > > - Impact on future developments: Say capability-enabled root-less Linux
> > > distributions. How will capabilities be handled for devices? Now there
> > > will have to be an all-powerful device manager... want to bet what
> > > crackers will start to try at after getting into your system?
capabilities aren't exactly centered in the scope of devfs. bringing up root-less
systems is a good point. without a single bit of media, i already have a working
/dev
> Capabilities can not be handled in user space. If they are, they are next
> to useless: The kernel won't be able to distinguish a faked capability
> handler from the real one, and the security you should get goes out the
> window. Same with permissions on devices: They have to be handled in the
> kernel, as they are way to important to be handled outside by insecure means.
policy can be dictated from userspace. not handling. same goes for permissions.
policy is handled by userland. save for policy set in /proc, the kernel doesn't
care what uid/gid/perms you place on a device, it only enforces them.
> > > Again, /dev might not scale well, but it is a non-problem. I have yet to
> > For you.
> And everybody else I've ever met.
have you had 200 active users on your system and found that you're out of ttys due
to the structure? you keep trying to say things are a moot point because you
haven't reached that limitation. other people have.
> > > see a machine with hundreds of devices. And the network around here, that
> > I have.
>
> Great! How is it handled? What percentage of the admin time goes into
> managing devices? 1%? 0.1%? Less? More? 10%? 20%?
how much is too much time? i don't think my shop policy should be dictated by you.
if i can shave 5 minutes off the workload of six employees per day, that's two and a
half hours per week. it is certainly of worth to me.
> > > is certainly made of hundreds of devices, isn't reconfigured willy-nilly.
> > Some need to be.
> Which ones? Why? How is that managed now? How will a simple naming scheme
> for devices make the work simpler? By how much?
in one word, a much higher level of accuracy being that the admins don't do it so
they don't make typos or assign wrong values.
i don't rely on m$ to assure me of security, neither do i rely on rpms to dictate
how things go on my network. if i counted all the exploits and vulnerabilities due
to poorly setup packages and policy dictated "for the mass" i could count dozens of
times when my network remained secure from exploitation and distributions madly
whipped up a patch.
in a parallel, we have dhcp. i used to use the argument of why we shouldn't use
dhcp because my scripts worked just dandy. when you're managing enterprise
networks, you DON'T have time to run things this way. luckily i stopped being
stubborn and learned better ways.
> > devfs solves so many more problems than "naming issues" that this isn't
> > even funny.
> WHAT problems, exactly, does devfs (which is just a naming scheme) solve?
ttys comes to mind.
> There is yet to be the "first set of dynamic devices" (USB), the discussion
> started precisely on how to handle them. If devfs really did solve all, the
> discussion would not even have started. That it did shows precisely that
> devfs does _not_ solve the issues involved.
it shows that the current implementation didn't match the requirements. i have no
doubt that the two could bring their heads together and make magic happen.
there is always version 1 of a concept. and invariable, version 2 and so on.
if we insist on never putting concepts into the kernel because they aren't perfect,
then we'll never get anywhere.
-d
-- This is Linux Country. On a quiet night, you can hear Windows NT reboot! Do you remember how to -think- ? Do you remember how to experiment? Linux __ is an operating system that brings back the fun and adventure in computing. \/ for linux-kernel: please read linux/Documentation/* before posting problems
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/