Re: issue with unsetting 'arch' flag
On Thu, Oct 7, 2010 at 3:36 AM, Alexander Best wrote: > On Wed Oct 6 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wrote: >> > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: >> >> On 6 October 2010 23:38, Alexander Best wrote: >> >>> On Wed Oct 6 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best >> wrote: >> > On Wed Oct 6 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`. >> >> > ^^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.XX` >> >> $ chflags arch $tmpfile >> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> >> $ rm $tmpfile >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> >> $ 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.XX >> > $ tmpfile=`mktemp /tmp/chflags.XX` >> > $ 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.XX` >> $ 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. >> >>> >> >> >> >> 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) >> > >> > _very_ interesting: >> > >> > [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn >> > fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; >> > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) >> > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) >> > >> > The commit that introduced this change probably wasn't doing the >> > right thing: >> > http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup >> > ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. >> > >> >> - ufs_setattr() does not handle unsetting SF_ARCHIVED, >> >> so al
Re: issue with unsetting 'arch' flag
On Thu, Oct 7, 2010 at 11:45 AM, Jaakko Heinonen wrote: > On 2010-10-06, Alexander Best wrote: >> $ sudo rm -d /tmp/chflags.XX >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ sudo chflags arch $tmpfile >> $ chflags noarch $tmpfile >> >> is what's causing the problem. the last chflags call should fail, but it >> doesn't. > > Here is a patch for UFS: > > %%% > Index: sys/ufs/ufs/ufs_vnops.c > === > --- sys/ufs/ufs/ufs_vnops.c (revision 213507) > +++ sys/ufs/ufs/ufs_vnops.c (working copy) > @@ -556,6 +556,9 @@ ufs_setattr(ap) > & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND) || > (vap->va_flags & UF_SETTABLE) != vap->va_flags) > return (EPERM); > + if ((ip->i_flags & SF_SETTABLE) != > + (vap->va_flags & SF_SETTABLE)) > + return (EPERM); > ip->i_flags &= SF_SETTABLE; > ip->i_flags |= (vap->va_flags & UF_SETTABLE); > DIP_SET(ip, i_flags, ip->i_flags); > %%% > > The patch has a potential to break something if someone assumes that > non-super-user can modify UF_SETTABLE flags with the SF_SETTABLE part > set to zero. However with a quick peek this seems to be what NetBSD > does. This seems ok in terms of the original issue that Alexander reported. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Thu, Oct 7, 2010 at 12:43 PM, Sergey Kandaurov wrote: > On 7 October 2010 22:45, Jaakko Heinonen wrote: >> On 2010-10-06, Alexander Best wrote: >>> $ sudo rm -d /tmp/chflags.XX >>> $ tmpfile=`mktemp /tmp/chflags.XX` >>> $ sudo chflags arch $tmpfile >>> $ chflags noarch $tmpfile >>> >>> is what's causing the problem. the last chflags call should fail, but it >>> doesn't. >> >> Here is a patch for UFS: >> >> %%% >> Index: sys/ufs/ufs/ufs_vnops.c >> === >> --- sys/ufs/ufs/ufs_vnops.c (revision 213507) >> +++ sys/ufs/ufs/ufs_vnops.c (working copy) >> @@ -556,6 +556,9 @@ ufs_setattr(ap) >> & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND) || >> (vap->va_flags & UF_SETTABLE) != vap->va_flags) >> return (EPERM); >> + if ((ip->i_flags & SF_SETTABLE) != >> + (vap->va_flags & SF_SETTABLE)) >> + return (EPERM); >> ip->i_flags &= SF_SETTABLE; >> ip->i_flags |= (vap->va_flags & UF_SETTABLE); >> DIP_SET(ip, i_flags, ip->i_flags); >> %%% >> >> The patch has a potential to break something if someone assumes that >> non-super-user can modify UF_SETTABLE flags with the SF_SETTABLE part >> set to zero. However with a quick peek this seems to be what NetBSD >> does. > > Just for reference: > this comes from NetBSD PR kern/3491 and fixed before 1.3R. > I just checked arch test, and it works as expected with the change. > All chflags tests from fstest suite passed as well. This only potentially fixes UFS though -- not ext*, msdosfs, ntfs, ZFS, etc, which that it can still fail the requirement in the chflags(2) manpage that states: [EOPNOTSUPP] The underlying file system does not support file flags. Or should it be a different requirement, i.e. EINVAL for bogus values? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On 7 October 2010 22:45, Jaakko Heinonen wrote: > On 2010-10-06, Alexander Best wrote: >> $ sudo rm -d /tmp/chflags.XX >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ sudo chflags arch $tmpfile >> $ chflags noarch $tmpfile >> >> is what's causing the problem. the last chflags call should fail, but it >> doesn't. > > Here is a patch for UFS: > > %%% > Index: sys/ufs/ufs/ufs_vnops.c > === > --- sys/ufs/ufs/ufs_vnops.c (revision 213507) > +++ sys/ufs/ufs/ufs_vnops.c (working copy) > @@ -556,6 +556,9 @@ ufs_setattr(ap) > & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND) || > (vap->va_flags & UF_SETTABLE) != vap->va_flags) > return (EPERM); > + if ((ip->i_flags & SF_SETTABLE) != > + (vap->va_flags & SF_SETTABLE)) > + return (EPERM); > ip->i_flags &= SF_SETTABLE; > ip->i_flags |= (vap->va_flags & UF_SETTABLE); > DIP_SET(ip, i_flags, ip->i_flags); > %%% > > The patch has a potential to break something if someone assumes that > non-super-user can modify UF_SETTABLE flags with the SF_SETTABLE part > set to zero. However with a quick peek this seems to be what NetBSD > does. Just for reference: this comes from NetBSD PR kern/3491 and fixed before 1.3R. I just checked arch test, and it works as expected with the change. All chflags tests from fstest suite passed as well. -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On 2010-10-06, Alexander Best wrote: > $ sudo rm -d /tmp/chflags.XX > $ tmpfile=`mktemp /tmp/chflags.XX` > $ sudo chflags arch $tmpfile > $ chflags noarch $tmpfile > > is what's causing the problem. the last chflags call should fail, but it > doesn't. Here is a patch for UFS: %%% Index: sys/ufs/ufs/ufs_vnops.c === --- sys/ufs/ufs/ufs_vnops.c (revision 213507) +++ sys/ufs/ufs/ufs_vnops.c (working copy) @@ -556,6 +556,9 @@ ufs_setattr(ap) & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND) || (vap->va_flags & UF_SETTABLE) != vap->va_flags) return (EPERM); + if ((ip->i_flags & SF_SETTABLE) != + (vap->va_flags & SF_SETTABLE)) + return (EPERM); ip->i_flags &= SF_SETTABLE; ip->i_flags |= (vap->va_flags & UF_SETTABLE); DIP_SET(ip, i_flags, ip->i_flags); %%% The patch has a potential to break something if someone assumes that non-super-user can modify UF_SETTABLE flags with the SF_SETTABLE part set to zero. However with a quick peek this seems to be what NetBSD does. -- Jaakko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed Oct 6 10, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wrote: > > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: > >> On 6 October 2010 23:38, Alexander Best wrote: > >>> On Wed Oct 6 10, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best > wrote: > > On Wed Oct 6 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`. > >> > ^^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.XX` > >> $ chflags arch $tmpfile > >> chflags: /tmp/chflags.nQm1IL: Operation not permitted > >> $ rm $tmpfile > >> $ tmpfile=`mktemp /tmp/chflags.XX` > >> $ 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.XX > > $ tmpfile=`mktemp /tmp/chflags.XX` > > $ 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.XX` > $ 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. > >>> > >> > >> 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) > > > > _very_ interesting: > > > > [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn > > fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; > > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) > > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) > > > > The commit that introduced this change probably wasn't doing the > > right thing: > > http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup > > ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. > > > >> - ufs_setattr() does not handle unsetting SF_ARCHIVED, > >> so all what it does is simply return zero. > > > > [EOPNOTSUPP] The underlying file system does not support file > > flags. > > > > So I would expect for invalid flags to return EOPNO
Re: issue with unsetting 'arch' flag
On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: >> On 6 October 2010 23:38, Alexander Best wrote: >>> On Wed Oct 6 10, Garrett Cooper wrote: On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: > On Wed Oct 6 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`. >> > ^^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.XX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> $ rm $tmpfile >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ 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.XX > $ tmpfile=`mktemp /tmp/chflags.XX` > $ 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.XX` $ 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. >>> >> >> 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) > > _very_ interesting: > > [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn > fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) > > The commit that introduced this change probably wasn't doing the > right thing: > http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup > ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. > >> - ufs_setattr() does not handle unsetting SF_ARCHIVED, >> so all what it does is simply return zero. > > [EOPNOTSUPP] The underlying file system does not support file > flags. > > So I would expect for invalid flags to return EOPNOTSUPP. > > ... > > $ ~/test_chflags_negative > test_chflags_negative: should not get here > $ sudo ~/test_chflags_negative > test_chflags_negative: should not get here > > *facepalm* > > I think the problem in part is here (sys/stat.h): > > * > * Super-user and owner changeable flags. > */ > #define
Re: issue with unsetting 'arch' flag
On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: > On 6 October 2010 23:38, Alexander Best wrote: >> On Wed Oct 6 10, Garrett Cooper wrote: >>> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: >>> > On Wed Oct 6 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`. >>> >> > ^^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.XX` >>> >> $ chflags arch $tmpfile >>> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >>> >> $ rm $tmpfile >>> >> $ tmpfile=`mktemp /tmp/chflags.XX` >>> >> $ 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.XX >>> > $ tmpfile=`mktemp /tmp/chflags.XX` >>> > $ 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.XX` >>> $ 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. >> > > 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) _very_ interesting: [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) The commit that introduced this change probably wasn't doing the right thing: http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. > - ufs_setattr() does not handle unsetting SF_ARCHIVED, > so all what it does is simply return zero. [EOPNOTSUPP] The underlying file system does not support file flags. So I would expect for invalid flags to return EOPNOTSUPP. ... $ ~/test_chflags_negative test_chflags_negative: should not get here $ sudo ~/test_chflags_negative test_chflags_negative: should not get here *facepalm* I think the problem in part is here (sys/stat.h): * * Super-user and owner changeable flags. */ #define UF_SETTABLE 0x /* mask of owner changeable flags */ #define UF_NODUMP 0x0001 /* do not dump file */ #define UF_IMMUTABLE0x0002 /* file may not be changed */ #define UF_APPEND
Re: issue with unsetting 'arch' flag
On 6 October 2010 23:38, Alexander Best wrote: > On Wed Oct 6 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: >> > On Wed Oct 6 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`. >> >> > ^^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.XX` >> >> $ chflags arch $tmpfile >> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> >> $ rm $tmpfile >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> >> $ 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.XX >> > $ tmpfile=`mktemp /tmp/chflags.XX` >> > $ 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.XX` >> $ 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. > 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, -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed Oct 6 10, Garrett Cooper wrote: > On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: > > On Wed Oct 6 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`. > >> > ^^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.XX` > >> $ chflags arch $tmpfile > >> chflags: /tmp/chflags.nQm1IL: Operation not permitted > >> $ rm $tmpfile > >> $ tmpfile=`mktemp /tmp/chflags.XX` > >> $ 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.XX > > $ tmpfile=`mktemp /tmp/chflags.XX` > > $ 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.XX` > $ 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 > >> r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > Thanks, > -Garrett -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best wrote: > On Wed Oct 6 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`. >> > ^^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.XX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> $ rm $tmpfile >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ 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.XX > $ tmpfile=`mktemp /tmp/chflags.XX` > $ 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.XX` $ 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). >> 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 >> r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wed Oct 6 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`. > > ^^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.XX` > $ chflags arch $tmpfile > chflags: /tmp/chflags.nQm1IL: Operation not permitted > $ rm $tmpfile > $ tmpfile=`mktemp /tmp/chflags.XX` > $ 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.XX $ tmpfile=`mktemp /tmp/chflags.XX` $ sudo chflags arch $tmpfile $ chflags noarch $tmpfile is what's causing the problem. the last chflags call should fail, but it doesn't. cheers. alex > > 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 > r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
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`. > ^^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.XX` $ chflags arch $tmpfile chflags: /tmp/chflags.nQm1IL: Operation not permitted $ rm $tmpfile $ tmpfile=`mktemp /tmp/chflags.XX` $ sudo chflags arch $tmpfile $ sudo chflags noarch $tmpfile $ rm $tmpfile 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 r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 test_chflags.c Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Wednesday 06 October 2010 00:50:54 Alexander Best wrote: > `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 guess that should be "sudo chflags arch ftest"? -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
