From: Goffredo Baroncelli <kreijack@inwind.it>
To: David Sterba <dsterba@suse.cz>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: make root id query unprivileged
Date: Wed, 13 May 2015 18:41:54 +0200 [thread overview]
Message-ID: <55537ED2.2050801@inwind.it> (raw)
In-Reply-To: <1431450889-27968-1-git-send-email-dsterba@suse.cz>
Hi David,
On 2015-05-12 19:14, David Sterba wrote:
> The INO_LOOKUP ioctl can lookup path for a given inode number and is
> thus restricted. As a sideefect it can find the root id of the
> containing subvolume and we're using this int the 'btrfs inspect rootid'
> command.
>
> The restriction is unnecessary in case we set the ioctl args
> args::treeid = 0
> args::objectid = 256 (BTRFS_FIRST_FREE_OBJECTID)
>
> Then the path will be empty and the treeid is filled with the root id of
> the inode on which the ioctl is called. This behaviour is unchanged,
> after the root restriction is removed.
I think that make sense to add another ioctl instead of relaxing the privilege check
on the basis of the parameters.
If I read correctly the code, in this case the function
btrfs_search_path_in_tree() is not even called: it is requested to return only
BTRFS_I(inode)->root->root_key.objectid;
Goffredo
>
> Signed-off-by: David Sterba <dsterba@suse.cz>
> ---
>
> fs/btrfs/ioctl.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 1c22c6518504..578ff63a9b74 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2271,10 +2271,7 @@ static noinline int btrfs_ioctl_ino_lookup(struct file *file,
> {
> struct btrfs_ioctl_ino_lookup_args *args;
> struct inode *inode;
> - int ret;
> -
> - if (!capable(CAP_SYS_ADMIN))
> - return -EPERM;
> + int ret = 0;
>
> args = memdup_user(argp, sizeof(*args));
> if (IS_ERR(args))
> @@ -2282,13 +2279,28 @@ static noinline int btrfs_ioctl_ino_lookup(struct file *file,
>
> inode = file_inode(file);
>
> + /*
> + * Unprivileged query to obtain the containing subvolume root id. The
> + * path is reset so it's consistent with btrfs_search_path_in_tree.
> + */
> if (args->treeid == 0)
> args->treeid = BTRFS_I(inode)->root->root_key.objectid;
>
> + if (args->objectid == BTRFS_FIRST_FREE_OBJECTID) {
> + args->name[0] = 0;
> + goto out;
> + }
> +
> + if (!capable(CAP_SYS_ADMIN)) {
> + ret = -EPERM;
> + goto out;
> + }
> +
> ret = btrfs_search_path_in_tree(BTRFS_I(inode)->root->fs_info,
> args->treeid, args->objectid,
> args->name);
>
> +out:
> if (ret == 0 && copy_to_user(argp, args, sizeof(*args)))
> ret = -EFAULT;
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2015-05-13 16:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 17:14 [PATCH] btrfs: make root id query unprivileged David Sterba
2015-05-13 16:41 ` Goffredo Baroncelli [this message]
2015-05-13 17:02 ` David Sterba
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=55537ED2.2050801@inwind.it \
--to=kreijack@inwind.it \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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