issue with unsetting 'arch' flag

Alexander Best arundel at freebsd.org
Wed Oct 6 19:38:27 UTC 2010


On Wed Oct  6 10, Garrett Cooper wrote:
> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best <arundel at freebsd.org> wrote:
> > On Wed Oct  6 10, Garrett Cooper wrote:
> >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best <arundel at 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 at bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA  amd64
> 
> Thanks,
> -Garrett

-- 
a13x


More information about the freebsd-hackers mailing list