From owner-freebsd-stable Sat Aug 8 16:01:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05522 for freebsd-stable-outgoing; Sat, 8 Aug 1998 16:01:53 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from mail.kersur.net (mail.kersur.net [199.79.199.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA05517 for ; Sat, 8 Aug 1998 16:01:48 -0700 (PDT) (envelope-from dswartz@druber.com) Received: from manticore (manticore.druber.com [207.180.95.108]) by mail.kersur.net (8.8.8/8.8.8) with SMTP id TAA08013; Sat, 8 Aug 1998 19:01:27 -0400 (EDT) Message-Id: <3.0.5.32.19980808190123.00941670@mail.kersur.net> X-Sender: druber@mail.kersur.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 08 Aug 1998 19:01:23 -0400 To: Tom From: Dan Swartzendruber Subject: Re: Quota bug crashing system? Cc: Joe Gleason , freebsd-stable@FreeBSD.ORG In-Reply-To: References: <3.0.5.32.19980808152803.0094d820@mail.kersur.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 03:48 PM 8/8/98 -0700, Tom wrote: > >On Sat, 8 Aug 1998, Dan Swartzendruber wrote: > >> Speaking of quotas, maybe someone can enlighten me on a quota >> related issue: it seems that (at least as some 6 months or so ago), >> 2.2 didn't correctly handle SUID programs. e.g. if a SUID root >> process has done setuid() (whichever flavor) to some less privileged >> UID, the original (root) quota continues to apply. This is arguably >> a bug. From what I can tell looking at the code, the decision about > > Not quite. Quotas are done by file ownership, not the current uid. > > You should check that the file you are writing to is owned by someone >with the appropiate quota. Sorry, this is incorrect. I did do at least the minimal diligence to read through the code enough to understand this. Also, proving it by writing a trivial program that reproduces the bug (by setuid() to a user with a quota entry for the FS in question. The program, which is SUID root, can exceed the quota with no problems). Here is one of the problematic places (in ufs/ufs/ufs_quota.c): /* * If user would exceed their hard limit, disallow space allocation. */ if (ncurblocks >= dq->dq_bhardlimit && dq->dq_bhardlimit) { if ((dq->dq_flags & DQ_BLKS) == 0 && ip->i_uid == cred->cr_uid) { ^^^^^^^^^^^^^^^^^^^^^^^^^^ uprintf("\n%s: write failed, %s disk limit reached\n", ITOV(ip)->v_mount->mnt_stat.f_mntonname, quotatypes[type]); dq->dq_flags |= DQ_BLKS; } return (EDQUOT); } The underlined check is the problem. From what I can tell, the credential in question is generated when the process is created (at which time it has a uid of zero, and that is the effective quota UID forevermore). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message