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: <e33d0b65-fc0b-49ab-ba48-7a13327d88aa@talpey.com>
Date: Wed, 17 Apr 2024 14:59:50 -0400
From: Tom Talpey <tom@...pey.com>
To: David Howells <dhowells@...hat.com>, Paulo Alcantara <pc@...guebit.com>
Cc: Steve French <sfrench@...ba.org>, Shyam Prasad N <sprasad@...rosoft.com>,
 linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live
 connection

On 4/17/2024 10:38 AM, David Howells wrote:
> Paulo Alcantara <pc@...guebit.com> wrote:
> 
>> Consider the following example where a tcon is reused from different
>> CIFS superblocks:
>>
>>    mount.cifs //srv/share /mnt/1 -o ${opts} # new super, new tcon
>>    mount.cifs //srv/share/dir /mnt/2 -o ${opts} # new super, reused tcon
>>
>> So, /mnt/1/dir/foo and /mnt/2/foo will lead to different inodes.
>>
>> The two mounts are accessing the same tcon (\\srv\share) but the new
>> superblock was created because the prefix path "\dir" didn't match in
>> cifs_match_super().  Trust me, that's a very common scenario.
> 
> Why does it need to lead to a different superblock, assuming ${opts} is the

The tcon is a property of the SMB3 session, it's not shared nor is
it necessarily created at mount time.

Tom.

> same in both cases?  Can we not do as NFS does and share the superblock,
> walking during the mount process through the directory prefix to the root
> object?
> 
> In other words, why does:
> 
>      mount.cifs //srv/share /mnt/1 -o ${opts}
>      mount.cifs //srv/share/dir /mnt/2 -o ${opts}
> 
> give you a different result to:
> 
>      mount.cifs //srv/share /mnt/1 -o ${opts}
>      mount --bind /mnt/1/dir /mnt/2
> 
> David
> 
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ