From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-bc0e.mail.infomaniak.ch (smtp-bc0e.mail.infomaniak.ch [45.157.188.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03D302139A8 for ; Fri, 11 Oct 2024 11:04:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728644681; cv=none; b=BqElfQz5YaAOkZkReONvQ5I7rQ2fi9FT/1+Vjd4yGHMheQzrMZPeuSCeUyhCgVNw+3anbooCevmtCPNvVrsww2u03DnGmFFQBSVWxxy8IsMXwzuQPr/uF6qv37apn8isLMhHqgrUAyZMvYEicFJO+kF3yMBGyYlbheEU9vjdgL0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728644681; c=relaxed/simple; bh=VPyiv+boH04rAQzfKWU+RIvEJ7tilQRTQhwpGsC5gxk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uTM3JNDYzxXZgZkYN5PFTmdQZKbuMT+VrG+UBu12XiDzN4RiG1ridMtCT2fkwUYz58yC5FpStnGZqXBPN/WLPJFQ64BdMdhL8FhoAnFeo3dem92Abm2upo8zKQz4CP25VjtdXCO0bxx4UEc/di6Khh8Amy4AA97ZYKz6xyjzV8o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=lof0Uk0J; arc=none smtp.client-ip=45.157.188.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="lof0Uk0J" Received: from smtp-3-0001.mail.infomaniak.ch (unknown [IPv6:2001:1600:4:17::246c]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4XQ3fk1NhtztFY; Fri, 11 Oct 2024 13:04:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1728644670; bh=9Pi1LmPYo8qdspv2MNYu5cluFjYOEW3JdL7e9mPBGs0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lof0Uk0J4x/gqYHL7OJpFodgrdbjpTEceSXVnOOrTYQJK0i/79vIk5ONQnB9gMNmo KsKXExCdvaiWj+OaL8ZTEJlda4kZTb1dHmIQdcmg8qtqunQOuh4BCDubt/Mzd2y8si Ux72qe9snzSuQ9q18rKRnItjSaPNPnQMnuu+iFk0= Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4XQ3fj0d9szRdk; Fri, 11 Oct 2024 13:04:29 +0200 (CEST) Date: Fri, 11 Oct 2024 13:04:25 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Tetsuo Handa Cc: Christian Brauner , Paul Moore , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org, audit@vger.kernel.org, Trond Myklebust , Anna Schumaker , Alexander Viro , Jan Kara Subject: Re: [RFC PATCH v1 1/7] fs: Add inode_get_ino() and implement get_ino() for NFS Message-ID: <20241011.Di7Yoh5ikeiX@digikod.net> References: <20241010152649.849254-1-mic@digikod.net> <70645876-0dfe-449b-9cb6-678ce885a073@I-love.SAKURA.ne.jp> Precedence: bulk X-Mailing-List: audit@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <70645876-0dfe-449b-9cb6-678ce885a073@I-love.SAKURA.ne.jp> X-Infomaniak-Routing: alpha On Fri, Oct 11, 2024 at 07:12:17PM +0900, Tetsuo Handa wrote: > On 2024/10/11 0:26, Mickaël Salaün wrote: > > When a filesystem manages its own inode numbers, like NFS's fileid shown > > to user space with getattr(), other part of the kernel may still expose > > the private inode->ino through kernel logs and audit. > > I can't catch what you are trying to do. What is wrong with that? My understanding is that tomoyo_get_attributes() is used to log or expose access requests to user space, including inode numbers. Is that correct? If yes, then the inode numbers might not reflect what user space sees with stat(2). > > > Another issue is on 32-bit architectures, on which ino_t is 32 bits, > > whereas the user space's view of an inode number can still be 64 bits. > > Currently, ino_t is 32bits on 32-bit architectures, isn't it? > Why do you need to use 64bits on 32-bit architectures? ino_t is indeed 32 bits on 32-bit architectures, but user space can still get a 64-bit stat->ino value. > > > Add a new inode_get_ino() helper calling the new struct > > inode_operations' get_ino() when set, to get the user space's view of an > > inode number. inode_get_ino() is called by generic_fillattr(). > > What does the user space's view of an inode number mean? It's the value user space gets with stat(2). > What does the kernel space's view of an inode number mean? It's struct inode->i_ino and ino_t variables.