From: Dave Chinner <david@fromorbit.com>
To: "L.A. Walsh" <xfs@tlinx.org>
Cc: xfs-oss <linux-xfs@vger.kernel.org>
Subject: Re: suggested patch to allow user to access their own file...
Date: Sun, 10 Jan 2021 08:13:47 +1100 [thread overview]
Message-ID: <20210109211347.GL331610@dread.disaster.area> (raw)
In-Reply-To: <5FEB204B.9090109@tlinx.org>
On Tue, Dec 29, 2020 at 04:25:47AM -0800, L.A. Walsh wrote:
> xfs_io checks for CAP_SYS_ADMIN in order to open a
> file_by_inode -- however, if the file one is opening
> is owned by the user performing the call, the call should
> not fail.
No. xfs_open_by_handle() requires root permissions because it
bypasses lots of security checks, such as parent directory
permissions, ACLs and security labels.
e.g. backups under a root-only directory heirarchy should not be
accessible to users because users are not allowed to traverse into
those root:root 0700 backup directories because permissions on the
directory inodes do not allow non-root users to enter them.
Hence ...
> (i.e. it opens the user's own file).
... the user doesn't actually own that file, even though it has
their own UID in it...
> It gets rid of some unnecessary error messages if you
> run xfs_restore to restore one of your own files.
That's not really a user case xfs_restore is intended to support.
It's an admin tool to be run by admins, not end users....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2021-01-09 21:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-29 12:25 suggested patch to allow user to access their own file L.A. Walsh
2021-01-04 17:08 ` Brian Foster
2021-01-04 18:44 ` Darrick J. Wong
[not found] ` <5FF3796E.5050409@tlinx.org>
2021-01-04 23:15 ` Darrick J. Wong
2021-01-05 0:03 ` L A Walsh
2021-01-09 21:13 ` Dave Chinner [this message]
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=20210109211347.GL331610@dread.disaster.area \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=xfs@tlinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.