Re: Poor interaction between chown and quota
On Thu, 2 Apr 1998, Nathan E Norman wrote:
> On Thu, 2 Apr 1998, Pete Templin wrote:
>
> :
> : Hi:
> :
> : In the process of debugging a variety of quota problems visible in
> : procmail-based mail delivery and qpopper-based mail pickup, I believe I've
> : identified an interaction problem between chown and quota. Essentially,
> : if a program running as superuser creates/appends/edits a file which would
> : put the user over soft quota, and then chown's it to the appropriate user,
> : the user is considered over soft quota with NO grace period. I've already
> : found this to be problematic in the following situations:
> :
> : 1) I use sendmail with procmail as the local delivery agent. If an
> : incoming message would put the user over soft quota, the message is
> : returned undeliverable with the message "overquota". IMHO, this shouldn't
> : happen unless the user would exceed hard quota or has expired his/her
> : grace period. The tricky part is I use a perl script run out of cron to
> : notify people if they're over quota...unfortunately I notify via email.
>
> Hmm, I hadn't noticed this (yet). I will test and try to confirm.
>
> : 2) I use qpopper to offer email to our customers. Quotas are enforced
> : (10M soft, 21M hard) on the /var partition, which therefore limits both
> : the user's mailbox and the corresponding copy which qpopper creates
> : beneath /var/spool/pop . Since the user's mailbox can't exceed 10M (see
> : problem 1, above), the user can't (easily) exceed 20M of disk usage while
> : qpopper has the /var/spool/pop/username.pop file in use, so the user can't
> : exceed their hard quota. Some of our users are unable to POP their mail
> : because of the following error:
> :
> : Apr 1 13:15:59 webhost in.qpopper[8981]: aew@jdm16.jdweb.com: -ERR Unable
> : to copy mail spool file, quota exceeded (122)
>
> Since quotas are filesystem based, you must plan your filesystem
> layout accordingly. The only easy way around this is to either insure
> that /var/spool/mail and /var/spool/pop are seperate filesystems, or
> grab the qpopper sources and make popper put its tempfiles somewhere
> other than /var/spool/pop ... preferably a seperate filesystem. I don't
> think you can blame the second problem on qpopper.
This would solve problem 2, but not problem 1. I have a wonderful
workaround for problem 2: NFS mount /var/spool/mail on another server,
install qpopper, and change the IP address of pop.jdweb.com. However,
this only works if management & store staff (which are the same two
people) used the correct hostnames in everyone's setup. :)
I figure the problem is somewhere between the chown system call and quota,
but I'm not sure.
Looking forward to your ideas and suggestions, or directions towards what
to file a bugreport on...
Pete
--
Peter J. Templin, Jr.
Systems and Networks Administrator
JD-WEB Computer Sales and Service
429 Market St. templin@jdweb.com
Lewisburg, PA 17837 (717)523-6800
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: