Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Nov 1995 23:39:28 +0100 (MET)
From:      J Wunsch <j@uriah.heep.sax.de>
To:        freebsd-hackers@freebsd.org (FreeBSD hackers)
Cc:        lyndon@orthanc.com (Lyndon Nerenberg)
Subject:   Re: Automounting CD-ROMs
Message-ID:  <199511022239.XAA16203@uriah.heep.sax.de>
In-Reply-To: <199511021912.LAA05649@multivac.orthanc.com> from "Lyndon Nerenberg" at Nov 2, 95 11:12:45 am

next in thread | previous in thread | raw e-mail | index | archive | help
As Lyndon Nerenberg wrote:
> 
> 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.

The SGI manager also didn't buy this argument.  They didn't buy it in
a lot of places, and the result was an operating system that nobody
does really wanna use. :-)

> Personally, I don't care whether we handle the problem with a daemon
> or standalone command,

That wasn't the point.  However, i think "on demand" (``automount'')
is better than "in advance, since there might be some demand some time
later" (``mediad'').

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

Even SGI fails this criterium.  Simply log in as luser-2 over the
network, type "eject" (well, sometimes you have to type something
obvious like "eject /dev/rdsk/fds0d2.3.5.20m" instead :), and *plong*,
luser-1 will happily pick up his floptical right out of the slot. ;-)

But that doesn't mean i wouldn't agree to your wishlist.  Somebody has
to implement it however.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511022239.XAA16203>