[lustre-discuss] Disable identity_upcall and ACL

[Andreas Dilger]

On Jan 9, 2019, at 07:52, Daniel Kobras <kobras at puzzle-itc.de> wrote:
> 
> Hi Aurélien!
> 
> Am 09.01.19 um 14:30 schrieb Degremont, Aurelien:
>> The secondary group thing was ok to me. I got this idea even if there is some weird results during my tests. Looks like you can overwrite MDT checks if user and group is properly defined on client node. Cache effects?
> 
> In a talk I gave a decade ago, I described a problem with authorization
> due to inconsistencies between client and MDT, depending on whether
> metadata was in the client cache or not (see p. 23 of
> http://wiki.lustre.org/images/b/ba/Tuesday_lustre_automotive.pdf -- you
> really managed to challenge my memory ;-) I faintly remember Andreas
> commenting that the MDT was always supposed to be authoritative, even
> for cached content, and the experienced behaviour was a bug. Indeed,
> other than those prehistoric versions, I'm not aware of any
> inconsistencies in authorization due to cache effects.

If admins completely trust the client nodes (e.g. they are on a secure
network) or they completely _distrust_ them (e.g. subdirectory mounts
with nodemaps/idmaps and Kerberos/SSK to identify them), or the data
just isn't that secret, then allowing the client to handle the group
lookups instead of the MDS is mostly OK.  

The main issue is for new, uncached lookups from the client.  Since the
RPC only includes the UID, GID, and maybe one supplementary GID, it is
possible that the MDS (without the identity_upcall) may deny the lookup
because the request does not contain any IDs that would allow file access.

If the file is cached on the client, then the MDS doesn't get involved
at all, and the VFS has full access to the IDs and can make the decision
locally.  This may lead to inconsistent behaviour as the file moves in
and out of the client cache (e.g. a shared file that is accessed by
multiple users, some of which have direct UID/GID access, others which
only have access via supp GID).

This access pattern is fairly uncommon, however.

>> ACL is really the thing I was interested in. Who is validating the ACLs? MDT, client or both? Do you think ACL could be properly applied if user/groups are only defined on client side and identity_upcall is disabled on MDT side?
> 
> Posix ACLs use numeric uids and gids, just like ordinary permission
> bits. Evaluation is supposed to happens on the MDT for both. If you can
> do without secondary groups, there's no need for user and group
> databases on the MDT--numeric id will work fine. (Unless you use
> Kerberos, which will typically require user names for proper id mapping.

I believe the MDS is also verifying the file access via ACL, so if the
only reason a user can access the file is because of a supp GID that is
missing (due to no identity_upcall or inconsistent /etc/groups) then access
would be denied.  The other (maybe lesser?) risk is if access should be
denied because of a supplementary group, the MDS will actually allow access
to the inode to the client.  I'm not sure if the client will revalidate the
ACLs locally and deny this on first open or not.

In summary, no identity_upcall would _mostly_ work, especially for simple
usage modes.

I guess the other question is why you are interested to get rid of it, or
what issue you are seeing with it enabled?

Cheers, Andreas
---
Andreas Dilger
Principal Lustre Architect
Whamcloud