Date: Thu, 02 Nov 1995 11:12:45 -0800 From: Lyndon Nerenberg (VE7TCP) <lyndon@orthanc.com> To: Gary Palmer <gary@palmer.demon.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: Automounting CD-ROMs Message-ID: <199511021912.LAA05649@multivac.orthanc.com> In-Reply-To: Your message of "Thu, 02 Nov 1995 16:09:54 GMT." <1518.815328594@palmer.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Gary" == Gary Palmer <gary@palmer.demon.co.uk> writes:
Gary> I am not in total agreement with the principle. What happens
Gary> if you stick in an audio cd? Does it automatically play it?
Gary> Ugh.
You don't like your own audio CDs? :-) (And yes, that's what my Indy
workstation used to do.)
I mentioned mediad as one example of how to handle this scenario. I
didn't say "clone it, warts and all."
Filesystems have magic numbers or other identifiable characteristics
that let you determine the underlying FS type. I don't see it being
all that difficult to autodetect the FS type. In the case where the
daemon cannot determine a filesystem type (such as a raw tar to floppy)
it would simply ignore it.
I don't buy the argument that having the process hanging around is
going to burn a ton of memory. Most of the time the active code set
would be a short loop probing the device(s). The rest would page out
if real memory was scarce.
As for layering, this type of service doesn't belong in the kernel
any more than getty does. Where else could you put it but user space?
(If that was in fact the argument being alluded to (not by Gary).)
As for recognizing multiple filesystem types on a single media,
this is an interesting question. In most cases the two filesystems
contain identical contents in different FS formats. I wouldn't want to
make this a global assumption, though, and can imagine situations
where you would want access to all of them. Then again, I don't think
the current mount command handles this situation, either.
Personally, I don't care whether we handle the problem with a daemon
or standalone command, just so long as I (the sysadmin) can specify
what devices the lusers are and are *not* allowed to fiddle with,
and that if luser-1 mounts a volume, luser-2 cannot unmount it to
create a denial of service type attack. The (admittedly little)
thought I have put into this makes me think that such a mount should
be tagged with the PGRP of the mounting process, and unmounts only
be allowed by the same PGRP. (This is an extension of something I
was working on many years ago - how to handle read/write access for
users to tape drives. I envisioned a user mount command that would
prompt the operator to perform the mount, then fiddle the driver
to only allow device access by the mounting PGRP.)
Thinking about this a bit more, I *do* care if it's a daemon vs.
command. This functionality would have been *very* useful in the
public workstation labs at the University. Most of these WS users
had trouble logging in, let alone mounting floppies. Having the
system do it for them adheres to the Principal of Least Astonishment.
This raises the "brute force unmount" issue. For a read-only CDROM
it's not a problem. For something like a floppy I would settle for
forcing synchronous writes to the FS - something no worse than what
DOS provides. (You can only do so much, and at least most people are
familiar with the effects of yanking a DOS floppy too soon ...)
--lyndon (still on his first coffee of the day and rambling a bit :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511021912.LAA05649>