Re: Floppy handling

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Mon Jun 19 2000 - 12:59:16 EST


--------- Received message begins Here ---------

>
> Richard Stallman <rms@gnu.org> wrote in message
> news:<fa.h09h36v.1a1sro5@ifi.uio.no>...
>
> > Is there any possibility of making Linux handle file systems on
> > floppies like MSDOS, so that there is no need to explicitly mount and
> > unmount a floppy drive in order to access floppies through the file
> > system?
>
> In discussing this problem, several people had possible solutions which were
> all shot down with a similar counterargument: the kernel can't assume that
> the user who is using the floppy drive is at the console. Apparently,
> Windows can automount floppies in part because it makes the assumption that
> there is only one user on the machine--an assumption which Unices by design
> can't make.

Not true for NT. The problem is security, and could be solved (partially) by
being able to allocate the floppy as a resource. That can only be done
by a mount/umount sequence.

> I completely agree that the standard Linux kernel could never assume that
> only a single user is logged in. But I don't think we should completely
> disregard patches which require this assumption. There are quite a few
> desktop-workstation users who wouldn't mind gaining a usability advantage in
> exchange for losing some multiuser functionality.
>
> And if a user is going to apply a patch which makes that assumption in one
> place, he might as well go full-out and run a kernel which assumes that
> *everywhere*. Are there other places in the kernel where we could gain in
> usability (or speed) by assuming that only a single user is logged in,
> directly at the console?

The entire kernel depends on it - there is always at least one user logged in
(root daemons). The user logging in is the second.

> I imagine that this is an issue which won't be met with much enthusiasm by
> many kernel hackers, because they're not the sort of users who would want a
> patch which essentially lobotomizes the kernel. I think that in the general
> case, a multi-user Unix OS is vastly superior to a single-user Microsoft OS.
> But in pursuing world domination, GNU/Linux is going to have to appeal to
> people who would rather have their floppy drive automounted than be able to
> run their system remotely.

They can have it, but it will take a lot of discussion and testing before
anything can really be determined. Personally, I would like to just tell
the user to mount/umount the file system, but that eliminates being able
to use the floppy for other tasks (format, create file systems, make recovery
floppy for different systems, make a boot floppy,...).

> If anyone can think of other problems and potential solutions which have
> been rejected because the kernel can't assume just one user is logged in,
> please let me know.

Part of the problem is security - you don't want any user to remove/use the
floppy other than the owner of the floppy. This cannot be enforced since
anyone with physical access to the system can remove the floppy (mounted
or not). Removal of a mounted device will (nearly always) damage the
file system.

Another problem is that there are multiple filesystem types that may
be on the floppy. Neither Windows or NT deal with this.

Right now I just tell the users to use mtools.

It may be possible to restrict access to the floppy UNLESS the user is
present at the console, but this is very restrictive on the users and is
not a favored solution.

Anybody know if the latest C2 certification for NT allows the floppy to
be used? The previous certification did not allow for floppy/cd or network
but I haven't heard about the December announcement.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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/



This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:17 EST