Path: utzoo!attcan!uunet!cs.utexas.edu!natinst!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Trojan Horses
Message-ID: <18648@rpp386.cactus.org>
Date: 26 Oct 90 13:08:03 GMT
References: <1990Oct18.121818.9956@athena.mit.edu> <35111@cup.portal.com> <18619@rpp386.cactus.org> <12402:Oct2605:19:2790@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 48
X-Clever-Slogan: Recycle or Die.

In article <12402:Oct2605:19:2790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>> you have just required that all write() operations be performed
>> synchronously.
>
>Not at all. It doesn't even require that the server hear about the
>operation, because clients can be given ``windows'' upon the disk space.
>``Here, you can assume you have at least 5M until I tell you
>otherwise.''

bzzt.  wrong answer.  process A writes some stuff and still has
5MB.  process B writes some stuff and still has 5MB.  process A
goes crazy, writes a ton of data and uses up everything it has,
plus the 5MB.

now, do you extend the quota of process B by another 5MB?  how
does the server distinguish between process A and process B
when both exist over in the client end of the world?  you have
also just added state - process A can't write and process B
can.  now generalize it to a person who wants to grossly exceed
their quota, creates fifty process and starts writing.  process
number 1 .. 50 respectively reach their quotas and get to write
5MB for free.  increase "50" until you see with my point.

>What several participants in this discussion seem to be missing is that
>EDQUOT is *not* as disastrous as EIO and should *not* require such
>drastic measures as fsync()/O_SYNC. If the CPU and disks are perfectly
>reliable, then why should such synchronization be required? To put it
>differently, why can't an application be reliable under quota errors
>without going to all the real work necessary for general reliability?
>EDQUOT is a relatively ``normal'' condition compared to EIO.

the administration of the machine needs to answer that question.
given that most programs do not check for errors on write system
calls (try this: "$ (ulimit 0; passwd joe)" on a System V machine.
actually, don't - it trashes your password file.), why would
someone want to intentionally increase the number of write
system call failures???

the answer from a programmers point of view should be that if the
administration is stupid enough to put their trust in quotas,
they deserve the grief their users give them.  this may not be a
nice answer, but i like it ;-)  this is an administrative problem
that can't be solved by programmers.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson