Date: Thu, 7 Oct 2010 17:34:59 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Sergey Kandaurov <pluknet@gmail.com> Cc: Jaakko Heinonen <jh@freebsd.org>, freebsd-hackers@freebsd.org, Alexander Best <arundel@freebsd.org> Subject: Re: issue with unsetting 'arch' flag Message-ID: <AANLkTi=%2BT0d7U7KcetnWzv-8Fw4KtMpOkHXv-EMZ0Wn_@mail.gmail.com> In-Reply-To: <AANLkTinp=tE0nZo10YV9T1hTmSvpiQuSc9jU8nOdv3k9@mail.gmail.com> References: <20101005235054.GA45827@freebsd.org> <AANLkTi=sA4GP=B61tbEmG6B0CYcET=dCFMJByoS_5=yi@mail.gmail.com> <20101006173522.GA92402@freebsd.org> <20101007184549.GA76070@a91-153-123-205.elisa-laajakaista.fi> <AANLkTinp=tE0nZo10YV9T1hTmSvpiQuSc9jU8nOdv3k9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 7, 2010 at 12:43 PM, Sergey Kandaurov <pluknet@gmail.com> wrote= : > On 7 October 2010 22:45, Jaakko Heinonen <jh@freebsd.org> wrote: >> On 2010-10-06, Alexander Best wrote: >>> $ 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 i= t >>> doesn't. >> >> Here is a patch for UFS: >> >> %%% >> Index: sys/ufs/ufs/ufs_vnops.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/ufs/ufs/ufs_vnops.c =A0 =A0 (revision 213507) >> +++ sys/ufs/ufs/ufs_vnops.c =A0 =A0 (working copy) >> @@ -556,6 +556,9 @@ ufs_setattr(ap) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0& (SF_NOUNLINK | = SF_IMMUTABLE | SF_APPEND) || >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(vap->va_flags & = UF_SETTABLE) !=3D vap->va_flags) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (E= PERM); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ip->i_flags & SF_SETT= ABLE) !=3D >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (vap->va_flags & S= F_SETTABLE)) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (EP= ERM); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ip->i_flags &=3D SF_SETTA= BLE; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ip->i_flags |=3D (vap->va= _flags & UF_SETTABLE); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DIP_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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=%2BT0d7U7KcetnWzv-8Fw4KtMpOkHXv-EMZ0Wn_>