From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 6 22:01:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B81BC106566C for ; Wed, 6 Oct 2010 22:01:36 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43A358FC08 for ; Wed, 6 Oct 2010 22:01:36 +0000 (UTC) Received: by vws2 with SMTP id 2so52921vws.13 for ; Wed, 06 Oct 2010 15:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k12gVRm1ZC92JH8wH+B2oFAhMd7zyR+gjRrXlbUbo5A=; b=HXCizDSp54NS2mNjW9Mroy9E0K34Q+qUmzv+2ko+qAietKcMzUhYXEppTvsY/qtxCA X8XcnGZgov8GBueclHUNErdIT0NszSdwICmL1Ufw4YNeDWC2+X4JDWmlzvw2fmt81pB/ lGa0Ron+CBSl5vq3b12U/DhN4XV0Uk0jtMIrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DKlh4e1sAGek/B0lhbRcPYCiMY/1tATvdFkUxFlolkGJ6jgnYTd6Cg6JWsQUnaWduz puPWNOChRahFG5AptKXJhuH/gfSEMK5wRkZRyCQLrCissnUbfmwlEy2txOdZXyIgQzqk OeMqWzk3nUZWjbW6tMgwTE1ZGnS9mfcGkae2g= MIME-Version: 1.0 Received: by 10.229.95.73 with SMTP id c9mr9279803qcn.111.1286402494618; Wed, 06 Oct 2010 15:01:34 -0700 (PDT) Received: by 10.229.50.8 with HTTP; Wed, 6 Oct 2010 15:01:34 -0700 (PDT) In-Reply-To: <20101006193827.GA13528@freebsd.org> References: <20101005235054.GA45827@freebsd.org> <20101006173522.GA92402@freebsd.org> <20101006193827.GA13528@freebsd.org> Date: Thu, 7 Oct 2010 02:01:34 +0400 Message-ID: From: Sergey Kandaurov To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Garrett Cooper Subject: Re: issue with unsetting 'arch' flag X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 22:01:36 -0000 On 6 October 2010 23:38, Alexander Best wrote: > On Wed Oct =A06 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wr= ote: >> > On Wed Oct =A06 10, Garrett Cooper wrote: >> >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best = wrote: >> >> > hi there, >> >> > >> >> > i think the following example shows the problem better than a long = explanation: >> >> > >> >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >> >> > =A0^^non-root =A0 =A0 ^^root =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^non-r= oot >> >> > >> >> > chflags claims to have cleared the 'arch' flag (which should be imp= ossible as >> >> > non-root user), but indeed has done nothing. >> >> > >> >> > i've tried the same with 'sappnd' and that works as can be expected= . >> >> > >> >> > The issue was confirmed to exist in HEAD (me), stable/8 (pgollucc1,= jpaetzel) >> >> > and stable/7 (nox). >> >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails wi= th EPERM. >> >> >> >> =A0 =A0 Fails for me when I call the syscall directly, as I would exp= ect, >> >> and passes when I'm superuser: >> >> >> >> $ ./test_chflags >> >> (uid, euid) =3D (1000, 1000) >> >> test_chflags: chflags: Operation not permitted >> >> test_chflags: lchflags: Operation not permitted >> >> $ sudo ./test_chflags >> >> (uid, euid) =3D (0, 0) >> >> >> >> =A0 =A0 According to my basic inspection in strtofflags >> >> (.../lib/libc/gen/strtofflags.c), it works as well. >> >> =A0 =A0 And last but not least, executing the commands directly on th= e CLI work: >> >> >> >> $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> >> $ chflags arch $tmpfile >> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> >> $ rm $tmpfile >> >> $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> >> $ sudo chflags arch $tmpfile >> >> $ sudo chflags noarch $tmpfile >> >> $ rm $tmpfile >> > >> > thanks for your test app and helping out with this problem. i'm not su= re >> > however you understood the problem. probably i didn't explain it right= : >> > >> > $ sudo rm -d /tmp/chflags.XXXXXX >> > $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> > $ sudo chflags arch $tmpfile >> > $ chflags noarch $tmpfile >> > >> > is what's causing the problem. the last chflags call should fail, but = it >> > doesn't. >> >> Sorry... my CLI based example was stupid. I meant: >> >> $ tmpfile=3D`mktemp /tmp/chflags.XXXXXX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.V2NpXR: Operation not permitted >> $ chflags noarch $tmpfile >> $ rm $tmpfile >> >> Currently chflags(2) states: >> >> =A0 =A0 =A0The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED fla= gs may only >> =A0 =A0 =A0be set or unset by the super-user. =A0Attempts to set these f= lags by non- >> =A0 =A0 =A0super-users are rejected, >>> attempts by non-superusers to c= lear >> flags that >> =A0 =A0 =A0are already unset are silently ignored. <<< =A0These flags ma= y be set at any >> =A0 =A0 =A0time, but normally may only be unset when the system is in si= ngle-user >> =A0 =A0 =A0mode. =A0(See init(8) for details.) >> >> So this behavior is already well documented :). The EPERM section >> should really note SF_ARCHIVED though (whoever added the flag forgot >> to add that particular item to the ERRORS section). > > that's perfectly alright. clearing an unset flag shouldn't cause any erro= r to > be returned. however in my example arch *does* get set and still trying t= o > unset it as normal user doesn't return an error. > It's even more interesting. As far as I could parse the code: - UFS has no special handling for SF_ARCHIVED (I found only it for msdosfs) - ufs_setattr() does not handle unsetting SF_ARCHIVED, so all what it does is simply return zero. - /bin/chflags doesn't check the actual flags value from inode after calling chflags() syscall, and blindly assumes all is well, if chflags() returns with zero, --=20 wbr, pluknet