linux-kernel - Re: [PATCH 5/6] fuse: truncate file if async dio failed

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50D02550.3090903@parallels.com>
Date:	Tue, 18 Dec 2012 12:12:00 +0400
From:	"Maxim V. Patlasov" <mpatlasov@...allels.com>
To:	Brian Foster <bfoster@...hat.com>
CC:	<miklos@...redi.hu>, <dev@...allels.com>, <xemul@...allels.com>,
	<fuse-devel@...ts.sourceforge.net>, <linux-kernel@...r.kernel.org>,
	<devel@...nvz.org>
Subject: Re: [PATCH 5/6] fuse: truncate file if async dio failed

12/17/2012 11:04 PM, Brian Foster пишет:
> On 12/17/2012 09:13 AM, Maxim V. Patlasov wrote:
>> Hi,
>>
>> 12/15/2012 12:16 AM, Brian Foster пишет:
>>> On 12/14/2012 10:21 AM, Maxim V. Patlasov wrote:
> ...
>>>> +
>>> fuse_do_truncate() looks fairly close to fuse_do_setattr(). Is there any
>>> reason we couldn't make fuse_do_setattr() non-static, change the dentry
>>> parameter to an inode and use that?
>> fuse_do_setattr() performs extra checks that fuse_do_truncate() needn't.
>> Some of them are harmless, some not: fuse_allow_task() may return 0 if
>> task credentials changed. E.g. super-user successfully opened a file,
>> then setuid(other_user_uid), then write(2) to the file. write(2) doesn't
>> check uid, but fuse_do_truncate() - via fuse_allow_task() - does.
>>
> Conversely, what about the extra error handling bits in
> fuse_do_setattr() that do not appear in fuse_do_truncate() (i.e., the
> inode mode check, the change attributes call, updating the inode size,
> etc.)? It seems like we would want some of that code here.

Yes, they won't harm.

>
> fuse_setattr() is the only caller of fuse_do_setattr(), so why not embed
> some of the initial checks (such as fuse_allow_task()) there? I suppose
> we could pull out some of the error handling checks there as well if
> they are considered harmful to this post-write error truncate situation.

Makes sense. I like it especially because it allows to avoid code 
duplication (handling FUSE_SETATTR fuse-request).

> FWIW, I just tested a quick change that pulls up the fuse_allow_task()
> check (via instrumenting a write error) and it seems to work as
> expected. I can forward a patch if interested...

I did exactly the same before sending previous email :) In my tests it 
works as expected too (modulo fuse_allow_task() that we can move up). 
I'll re-send corrected patch soon.

Thanks,
Maxim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/