lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c4f58675-9df5-e3af-45fc-6fa924e3ee68@huawei.com>
Date:   Mon, 31 Aug 2020 10:31:17 +0800
From:   Chao Yu <yuchao0@...wei.com>
To:     Daeho Jeong <daeho43@...il.com>
CC:     Chao Yu <chao@...nel.org>, Daeho Jeong <daehojeong@...gle.com>,
        <kernel-team@...roid.com>, <linux-kernel@...r.kernel.org>,
        <linux-f2fs-devel@...ts.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH] f2fs: prevent compressed file from being
 disabled after releasing cblocks

On 2020/8/31 9:44, Daeho Jeong wrote:
> Sorry, I didn't get your point.
> 
> So, do you think this patch is ok? And we need to consider that we
> need more immutable checks for other cases?

Yes, this patch looks good to me.

But, IMO, we should discuss about whether we need to add more immutable checks
for other ioctl cases.

- open(O_RDWR)
- ioctl(FS_IOC_SETFLAGS, F2FS_COMPR_FL)
- write()
- ioctl(RELEASE_COMPRESS_BLOCKS) -- inode is immutable now
- ioctl(FS_IOC_SETFLAGS, ~F2FS_COMPR_FL) -- Should we allow to update immutable inode?
as we know, normally, immutable inode should deny open(O_WRONLY or O_RDWR) and later update.

Thanks,

> Or you want to remove this immutable check from here and add the check
> to each ioctl functions? >
> 2020년 8월 31일 (월) 오전 10:24, Chao Yu <yuchao0@...wei.com>님이 작성:
>>
>> On 2020/8/31 7:42, Daeho Jeong wrote:
>>> Do you have any reason not to put this check here?
>>
>> No, the place is okay to me. :)
>>
>>> If we do this check outside of here, we definitely make a mistake
>>> sooner or later.
>>
>> I just want to see whether we can cover all cases in where we missed to
>> add immutable check condition if necessary.
>>
>> Thanks,
>>
>>>
>>> 2020년 8월 30일 (일) 오후 12:24, Chao Yu <chao@...nel.org>님이 작성:
>>>>
>>>> On 2020-8-28 13:46, Daeho Jeong wrote:
>>>>> From: Daeho Jeong <daehojeong@...gle.com>
>>>>>
>>>>> After releasing cblocks, the compressed file can be accidentally
>>>>> disabled in compression mode, since it has zero cblocks. As we are
>>>>> using IMMUTABLE flag to present released cblocks state, we can add
>>>>> IMMUTABLE state check when considering the compressed file disabling.
>>>>>
>>>>> Signed-off-by: Daeho Jeong <daehojeong@...gle.com>
>>>>> ---
>>>>>    fs/f2fs/f2fs.h | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>>>> index 02811ce15059..14d30740ba03 100644
>>>>> --- a/fs/f2fs/f2fs.h
>>>>> +++ b/fs/f2fs/f2fs.h
>>>>> @@ -3936,6 +3936,8 @@ static inline u64 f2fs_disable_compressed_file(struct inode *inode)
>>>>>         if (!f2fs_compressed_file(inode))
>>>>>                 return 0;
>>>>>         if (S_ISREG(inode->i_mode)) {
>>>>> +             if (IS_IMMUTABLE(inode))
>>>>> +                     return 1;
>>>>
>>>> It looks most of callers are from ioctl, should we add immutable check in f2fs
>>>> ioctl interfaces if necessary? or I missed existed check.
>>>>
>>>> Thanks,
>>>>
>>>>>                 if (get_dirty_pages(inode))
>>>>>                         return 1;
>>>>>                 if (fi->i_compr_blocks)
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Linux-f2fs-devel mailing list
>>> Linux-f2fs-devel@...ts.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>>
> .
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ