Date: Wed, 6 Oct 2010 19:38:27 +0000 From: Alexander Best <arundel@freebsd.org> To: Garrett Cooper <gcooper@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: issue with unsetting 'arch' flag Message-ID: <20101006193827.GA13528@freebsd.org> In-Reply-To: <AANLkTi==F4zFmJxqOBzMCk%2Buci6XbvoQBe4mqxHjtbr6@mail.gmail.com> References: <20101005235054.GA45827@freebsd.org> <AANLkTi=sA4GP=B61tbEmG6B0CYcET=dCFMJByoS_5=yi@mail.gmail.com> <20101006173522.GA92402@freebsd.org> <AANLkTi==F4zFmJxqOBzMCk%2Buci6XbvoQBe4mqxHjtbr6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed Oct 6 10, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best <arundel@freebsd.org> wrote: > > On Wed Oct 6 10, Garrett Cooper wrote: > >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best <arundel@freebsd.org> 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`. > >> > ^^non-root ^^root ^^non-root > >> > > >> > chflags claims to have cleared the 'arch' flag (which should be impossible 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 with EPERM. > >> > >> Fails for me when I call the syscall directly, as I would expect, > >> and passes when I'm superuser: > >> > >> $ ./test_chflags > >> (uid, euid) = (1000, 1000) > >> test_chflags: chflags: Operation not permitted > >> test_chflags: lchflags: Operation not permitted > >> $ sudo ./test_chflags > >> (uid, euid) = (0, 0) > >> > >> According to my basic inspection in strtofflags > >> (.../lib/libc/gen/strtofflags.c), it works as well. > >> And last but not least, executing the commands directly on the CLI work: > >> > >> $ tmpfile=`mktemp /tmp/chflags.XXXXXX` > >> $ chflags arch $tmpfile > >> chflags: /tmp/chflags.nQm1IL: Operation not permitted > >> $ rm $tmpfile > >> $ tmpfile=`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 sure > > however you understood the problem. probably i didn't explain it right: > > > > $ sudo rm -d /tmp/chflags.XXXXXX > > $ tmpfile=`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=`mktemp /tmp/chflags.XXXXXX` > $ chflags arch $tmpfile > chflags: /tmp/chflags.V2NpXR: Operation not permitted > $ chflags noarch $tmpfile > $ rm $tmpfile > > Currently chflags(2) states: > > The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags may only > be set or unset by the super-user. Attempts to set these flags by non- > super-users are rejected, >>> attempts by non-superusers to clear > flags that > are already unset are silently ignored. <<< These flags may be set at any > time, but normally may only be unset when the system is in single-user > mode. (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 error to be returned. however in my example arch *does* get set and still trying to unset it as normal user doesn't return an error. please make sure to *only* run the first chflags instance as root. all other command must be run as normal user. > > >> Your results may (but shouldn't) vary [unless your environment is > >> setup differently]... > >> Please note that I'm using UFS2 with SUJ... not all filesystems > >> support this (ext2/3/4? msdosfs? ZFS?), so I would be careful about > >> which filesystem you pick and whether or not there's a bug where it's > >> not properly identifying that the operation you're attempting to > >> perform is valid. > >> Thanks, > >> -Garrett > >> > >> $ uname -a > >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211309M: > >> Thu Aug 19 22:50:36 PDT 2010 > >> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > Thanks, > -Garrett -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101006193827.GA13528>