> On Fri, 2009-11-13 at 07:58 +0100, Miklos Szeredi wrote:
>> On Thu, 12 Nov 2009, Josef Bacik wrote:
>> > Hello,
>> >
>> > There is a problem where if you have certain audit rules in place
>> > you can hang on mount of a fuse filesystem. If you follow the
>> > instructions here
>> >
>> >
https://bugzilla.redhat.com/show_bug.cgi?id=493565#c44
>> >
>> > it is easy to reproduce. The problem is after the mount request
>> > gets sent, the mounting process gets stuck going off to read xattrs
>> > to satisfy audit's curiosity, and then we get stuck because that
>> > tries to get a request, but can't because the connection is blocked.
>> > This patch fixes the problem, but I'm not entirely sold on it, it's
>> > rather quick and dirty. Basically if we haven't finished the
>> > initialization of the connection just return -EAGAIN. This fixes
>> > the problem, audit seems to be ok with getting that as an error.
>>
>> Why not rather fix audit not to do this?
>>
>> We had a similar problem in SMACK in the past, and my reasoning at the
>> time should apply here as well: calling into filesystem code before
>> it's fully initialized (i.e. mount is finished) is not guaranteed to
>> work for *any* filesystem. Fuse will hang, others may just see silent
>> memory corruption.
>>
>> So NACK, unless there's some fundamental reason why audit can't be
>> properly fixed.
>
> I don't buy the argument that audit did anything wrong.
>
> mount S ffff88001f86bd28 0 4126 4120 0x00000080
> mount S ffff88001f86bd28 0 4126 4120 0x00000080
> ffff88001f86bc38 0000000000000086 0000000000000011 ffff88001f86bc08
> 0000000000000700 0000000000000000 0000000000000013 ffffffff815884cd
> ffff8800377532c8 000000000000f8e0 ffff8800377532c8 0000000000015600
> Call Trace:
> [<ffffffffa01bec71>] fuse_get_req+0xb8/0x15b [fuse]
> [<ffffffffa01bf359>] fuse_getxattr+0x58/0x14f [fuse]
> [<ffffffff811b9ea2>] get_vfs_caps_from_disk+0x52/0xcd
> [<ffffffff81093809>] audit_copy_inode+0x83/0xb1
> [<ffffffff81093d4f>] __audit_inode+0x1ee/0x1fd
> [<ffffffff81104789>] audit_inode+0x28/0x2a
> [<ffffffff811066b4>] do_path_lookup+0x63/0x8b
> [<ffffffff81107c9c>] user_path_at+0x56/0x93
> [<ffffffff810ffaf0>] sys_readlinkat+0x2d/0x91
> [<ffffffff810ffb6f>] sys_readlink+0x1b/0x1d
> [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b
>
> Userspace called readlink() and the audit system (after the vfs worked
> out the path) needs to collect any fcaps. I don't agree, but would be
> willing to accept your argument that things like SELinux and SMACK can't
> make filesystem calls during the mount(2) operation but clearly this
> isn't done during a mount call, it's done by calling readlink. The
> mount syscall is finished and we still can't use the FS? How is Audit
> supposed to be 'fixed' ?
