linux-kernel - Re: [RFC PATCH 0/2] issues with NFS filesystems as lower layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120912160748.GF3009@fieldses.org>
Date:	Wed, 12 Sep 2012 12:07:48 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Andy Whitcroft <apw@...onical.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] issues with NFS filesystems as lower layer

On Wed, Sep 12, 2012 at 05:20:17PM +0200, Miklos Szeredi wrote:
> "J. Bruce Fields" <bfields@...ldses.org> writes:
> 
> > On Tue, Sep 11, 2012 at 10:56:52PM +0200, Miklos Szeredi wrote:
> >> "J. Bruce Fields" <bfields@...ldses.org> writes:
> >> 
> >> >> > Secondly when using an NFSv3 R/O lower layer the filesystem permissions
> >> >> > check refuses permission to write to the inode which prevents us from
> >> >> > copying it up even though we have a writable upper layer.  (With an ext4
> >> >> > lower layer the inode check will succeed if the inode  is writable even
> >> >> > if the filesystem is not.)  It is not clear what the right solution is
> >> >> > here.  One approach is to check the inode permissions only (avoiding the
> >> >> > filesystem specific permissions op), but it is not clear we can rely on
> >> >> > these for all underlying filesystems.  Perhaps this check should only be
> >> >> > used for NFS.
> >> >
> >> > Then couldn't you for example end up circumventing ACLs on the
> >> > underlying file to access data cached by reads from another user on the
> >> > same system?
> >> 
> >> Ignoring ACL's should always give less access, isn't that right?
> >
> > Not necessarily.
> >
> > (It's up to the server--and if anything servers probably want to err on
> > the side of returning mode bits that are an upper, not a lower, bound on
> > the permissions.)
> 
> Okay, I looked at the POSIX ACL access check algorithm and now
> understand things better.
> 
> Now i think that enforcing ACL's on the overlay is not possible if ACL's
> are not copied up together with the data.

And the NFSv4 case is different (it doesn't use "posix" acls), etc.,
etc.

But forget all that, even mode bits aren't much use since you don't
understand how the server might be mapping your uid, so you don't know
whether you're the owner, or a member of the group.

On the other hand, for some cases maybe what you want is to just forget
all that and trust the file owners and mode bits, so maybe that's useful
at least as an option.

> > Oh, OK, I guess I assumed you were dealing with an NFS filesystem that
> > had been mounted readonly on the NFS client.
> >
> > If it's a read-write mount of a filesystem that's read-only on the
> > server side: well, there is at least an error for that case: the server
> > should return NFSERR_ROFS, and you should see EROFS--could you do the
> > copy-up only in the case you get that error?
> 
> If the server returns EROFS then all you know is that the filesystem is
> read-only.  But that's not what we are interested in.  We are interested
> in whether the access would be allowed *if* the filesystem *wasn't*
> read-only.  The server doesn't tell us that.

Yeah.  I wonder if it would be reasonable in the future to let servers
tell us that.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/