On 2021/01/04 15:15, Darrick J. Wong wrote:
Cc: bfoster@xxxxxxxxxx, xfs-oss <xfs@xxxxxxxxxxxxxxxxxxxxxxxxxx>
akamaiedge.net ??
---
First I've seen that...
Er, did my mailer do that, or did yours?
[re-adding linux-xfs to cc]
On Mon, Jan 04, 2021 at 12:24:14PM -0800, L A Walsh wrote:
On 2021/01/04 10:44, Darrick J. Wong wrote:
This would open a huge security hole because users can use it to bypass
directory access checks.
---
Can't say I entirely disagree. Though given the prevalence of that
behavior being "normal" on NT due to the "Bypass Traverse Checking" "right"
being on by default in a standard Windows setup,
That might be true on Windows, but CAP_DAC_* isn't given out by default
on Linux.
----
Not quite the same as I understand it -- it allows ignoring
an 'X' permission of directories above the target, I believe, but not other
DAC permissions. I'd have to experiment to be sure. In their security
settings dialogue, they warn you against changing it away from the default
as it might cause compatibility problems.
I would question it being a 'huge' security hole, though it would be
an unwanted change in behavior.
I think people would consider it a hole of /some/ kind, since this patch
wouldn't even require the process to hold CAP_DAC_* privilege.
---
Yeah, though it doesn't allow overriding DAC settings on files
or directories that have them when trying to access them, just bypassing
directory traversal permissions for items lower in the hierarchy.
Yeah. As far as I can tell, CAP_DAC_OVERRIDE actually /does/ give you
the security permissions that you want. The sysadmin can then decide
who gets to have that permission, so you /could/ propose doing that.
----
Except that it does more than just allowing directory traversal
to a set of files you own. Like I think it might not be uncommon to have
some common home dir set restrictively, so you couldn't read who else had
home directories on the system, perhaps, but you could still cd through
it to your own directory. It may be more like allowing you to 'x' through
parent directories without being able to read/write to them. CAP_DAC_OVERRIDE
would allow you to override any DAC permissions on any file -- not just
ignore lack of 'X' on a directory.
If it isn't possible already, I'm sure it soon will be
the case that users will be on systems that have different file
systems mounted. If an xfs file system is mounted under an NT
file system and the user is running Windows, wouldn't NT-rights
(like ignoring traversal issues) apply by default, as NT would
be in charge of enforcing security as it walked through a locally
mounted XFS file system?
When would NT be walking through a locally mounted XFS filesystem?
Well, at least when it is mounted in a linux subsystem -- I haven't checked
out what's possible, but am told explorer can then be used to move through
file systems that are locally mounted through the linux drivers.
The other possibility -- is a stretch of locally mounted, in having
an XFS drive mounted via CIFS as a "local" drive. I'd think it would
allow bypassing traverse checking in the same way that having
NT-admin privileges can give you root access to exported drives, but
you have to set it up so that your login has those privs on the target server,
but less drastic privs, like bypassing traverse checking and having
a read/write access for a user that has the backup+restore privs are likely
also supported.
As an example, a Domain administrator on my NT workstation has root access
to my server (not by accident, but because it is meant to be that way).
I use Win as a desktop, but lin as my diskspace+server. My Win desktop barely
has enough diskspace for the OS + programs I have installed.
