On Jan 9, 2019, at 07:52, Daniel Kobras <kob...@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 _______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org