public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Erin Shepherd <erin.shepherd@e43.eu>,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	Chuck Lever <chuck.lever@oracle.com>
Cc: oe-kbuild-all@lists.linux.dev, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	linux-nfs@vger.kernel.org, Erin Shepherd <erin.shepherd@e43.eu>
Subject: Re: [PATCH v2 2/3] exportfs: allow fs to disable CAP_DAC_READ_SEARCH check
Date: Thu, 14 Nov 2024 09:29:42 +0800	[thread overview]
Message-ID: <202411140905.a0ntnQQG-lkp@intel.com> (raw)
In-Reply-To: <20241113-pidfs_fh-v2-2-9a4d28155a37@e43.eu>

Hi Erin,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 14b6320953a3f856a3f93bf9a0e423395baa593d]

url:    https://github.com/intel-lab-lkp/linux/commits/Erin-Shepherd/pseudofs-add-support-for-export_ops/20241114-020539
base:   14b6320953a3f856a3f93bf9a0e423395baa593d
patch link:    https://lore.kernel.org/r/20241113-pidfs_fh-v2-2-9a4d28155a37%40e43.eu
patch subject: [PATCH v2 2/3] exportfs: allow fs to disable CAP_DAC_READ_SEARCH check
config: openrisc-defconfig (https://download.01.org/0day-ci/archive/20241114/202411140905.a0ntnQQG-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241114/202411140905.a0ntnQQG-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202411140905.a0ntnQQG-lkp@intel.com/

All warnings (new ones prefixed by >>):

   fs/fhandle.c: In function 'may_decode_fh':
>> fs/fhandle.c:242:41: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
     242 |         struct export_operations *nop = root->mnt->mnt_sb->s_export_op;
         |                                         ^~~~


vim +/const +242 fs/fhandle.c

   237	
   238	static inline bool may_decode_fh(struct handle_to_path_ctx *ctx,
   239					 unsigned int o_flags)
   240	{
   241		struct path *root = &ctx->root;
 > 242		struct export_operations *nop = root->mnt->mnt_sb->s_export_op;
   243	
   244		if (nop && nop->flags & EXPORT_OP_UNRESTRICTED_OPEN)
   245			return true;
   246	
   247		if (capable(CAP_DAC_READ_SEARCH))
   248			return true;
   249	
   250		/*
   251		 * Allow relaxed permissions of file handles if the caller has the
   252		 * ability to mount the filesystem or create a bind-mount of the
   253		 * provided @mountdirfd.
   254		 *
   255		 * In both cases the caller may be able to get an unobstructed way to
   256		 * the encoded file handle. If the caller is only able to create a
   257		 * bind-mount we need to verify that there are no locked mounts on top
   258		 * of it that could prevent us from getting to the encoded file.
   259		 *
   260		 * In principle, locked mounts can prevent the caller from mounting the
   261		 * filesystem but that only applies to procfs and sysfs neither of which
   262		 * support decoding file handles.
   263		 *
   264		 * Restrict to O_DIRECTORY to provide a deterministic API that avoids a
   265		 * confusing api in the face of disconnected non-dir dentries.
   266		 *
   267		 * There's only one dentry for each directory inode (VFS rule)...
   268		 */
   269		if (!(o_flags & O_DIRECTORY))
   270			return false;
   271	
   272		if (ns_capable(root->mnt->mnt_sb->s_user_ns, CAP_SYS_ADMIN))
   273			ctx->flags = HANDLE_CHECK_PERMS;
   274		else if (is_mounted(root->mnt) &&
   275			 ns_capable(real_mount(root->mnt)->mnt_ns->user_ns,
   276				    CAP_SYS_ADMIN) &&
   277			 !has_locked_children(real_mount(root->mnt), root->dentry))
   278			ctx->flags = HANDLE_CHECK_PERMS | HANDLE_CHECK_SUBTREE;
   279		else
   280			return false;
   281	
   282		/* Are we able to override DAC permissions? */
   283		if (!ns_capable(current_user_ns(), CAP_DAC_READ_SEARCH))
   284			return false;
   285	
   286		ctx->fh_flags = EXPORT_FH_DIR_ONLY;
   287		return true;
   288	}
   289	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2024-11-14  1:29 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-01 13:54 [PATCH 0/4] pidfs: implement file handle support Erin Shepherd
2024-11-01 13:54 ` [PATCH 1/4] pseudofs: add support for export_ops Erin Shepherd
2024-11-12 15:56   ` Amir Goldstein
2024-11-01 13:54 ` [PATCH 2/4] pidfs: implement file handle export support Erin Shepherd
2024-11-12 15:55   ` Amir Goldstein
2024-11-01 13:54 ` [PATCH 3/4] pid: introduce find_get_pid_ns Erin Shepherd
2024-11-12 15:59   ` Amir Goldstein
2024-11-01 13:54 ` [PATCH 4/4] pidfs: implement fh_to_dentry Erin Shepherd
2024-11-12 16:33   ` Amir Goldstein
2024-11-12 23:51   ` Jeff Layton
2024-11-13  8:01     ` Amir Goldstein
2024-11-13 10:11       ` Erin Shepherd
2024-11-13 12:21         ` Christian Brauner
2024-11-13 12:09   ` Christian Brauner
2024-11-13 13:06     ` Erin Shepherd
2024-11-13 13:26       ` Christian Brauner
2024-11-13 13:48         ` Erin Shepherd
2024-11-14 10:29           ` Christian Brauner
2024-11-14 12:21             ` Erin Shepherd
2024-11-12 13:10 ` [PATCH 0/4] pidfs: implement file handle support Christian Brauner
2024-11-12 13:57   ` Jeff Layton
2024-11-12 22:43     ` Erin Shepherd
2024-11-13  0:37       ` Darrick J. Wong
2024-11-13 11:35       ` Christian Brauner
2024-11-13 17:55       ` [PATCH v2 0/3] " Erin Shepherd
2024-11-13 17:55         ` [PATCH v2 1/3] pseudofs: add support for export_ops Erin Shepherd
2024-11-13 17:55         ` [PATCH v2 2/3] exportfs: allow fs to disable CAP_DAC_READ_SEARCH check Erin Shepherd
2024-11-13 22:50           ` kernel test robot
2024-11-14  1:29           ` kernel test robot [this message]
2024-11-14  4:37           ` Christoph Hellwig
2024-11-14 12:56             ` Erin Shepherd
2024-11-14  6:37           ` Amir Goldstein
2024-11-14 14:16             ` Christian Brauner
2024-11-13 17:55         ` [PATCH v2 3/3] pidfs: implement file handle support Erin Shepherd
2024-11-14  7:07           ` Amir Goldstein
2024-11-14 12:42             ` Erin Shepherd
2024-11-14 12:52           ` Christian Brauner
2024-11-14 13:13             ` Erin Shepherd
2024-11-14 14:13               ` Christian Brauner
2024-11-14 21:52                 ` Erin Shepherd
2024-11-15  7:50                   ` Amir Goldstein
2024-11-14  7:02         ` [PATCH v2 0/3] " Amir Goldstein
2024-11-14 12:48           ` Erin Shepherd
2024-11-14 14:27             ` Christian Brauner
2024-11-28 12:33               ` [PATCH RFC 0/2] pidfs: file handle preliminaries Christian Brauner
2024-11-28 12:33                 ` [PATCH RFC 1/2] pidfs: rework inode number allocation Christian Brauner
2024-11-28 17:19                   ` Amir Goldstein
2024-11-28 12:33                 ` [PATCH RFC 2/2] pidfs: remove 32bit inode number handling Christian Brauner
2024-11-28 17:06                 ` [PATCH RFC 0/2] pidfs: file handle preliminaries Amir Goldstein
2024-11-14 16:10             ` [PATCH v2 0/3] pidfs: implement file handle support Amir Goldstein
2024-11-12 23:03   ` [PATCH 0/4] " Erin Shepherd
2024-11-13  0:40     ` Darrick J. Wong
2024-11-13 10:17       ` Erin Shepherd
2024-11-13 13:29         ` Jeff Layton
2024-11-13 14:41           ` Chuck Lever III
2024-11-14 10:39             ` Christian Brauner
2024-11-14  6:55           ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202411140905.a0ntnQQG-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=erin.shepherd@e43.eu \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox