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_>