LU-17961 sec: support supplementary groups from client

LU-17961 sec: support supplementary groups from client

The usual way to support more than 2 supplementary groups is to
resort to the server side's identity upcall. This identity upcall
retrieves all user's credentials, including all supplementary groups,
and stores them in cache. But this access to user's credentials from
server side is not always an option.

As an alternative to the server side's identity upcall, we implement
a retry mechanism for intent locking. The client can provide at most
2 supplementary groups in the request sent to the MDS, but sometimes
it does not know which ones are useful for credentials calculation on
server side. For instance in case of lookup, the client does not have
the child inode yet when it sends the intent lock request.
Hopefully, the server can hint at the useful groups, by putting in the
request reply the target inode's GID, and also its ACL. So, in case
the server replies -EACCES, we check the user's credentials against
those, and try again the intent lock request if we find a matching
supplementary group.

On server side, we add an INTERNAL dedicated, separate upcall cache.
This makes it distinct from the regular identity upcall cache that can
be defined to use any upcall including NONE, per an MDT side tuning.
It implements a particular behavior which does not involve an actual
upcall, but instead the cache is filled with supplementary groups read
from the client request, cumulatively at each request.
Dedicated mdt-side tunables are created to configure the entry expiry
time and the acquire expire time for INTERNAL, as well as a tunable to
flush the INTERNAL upcall cache.

A problem with the 'runas' utility was found during testing. If no
supplementary group is provided via the '-G' option, then it needs at
least to set the given GID as a supplementary group. Otherwise the
supplementary groups of the invoking user would be silently inherited.
For instance, if root user calls 'runas -u 500 -g 500 $CMD', we must
not execute $CMD with UID:GID 500:500 and supplementary group 0, as
it would make the user executing $CMD part of the superuser group.

Signed-off-by: Sebastien Buisson <sbuisson@ddn.com>
Change-Id: I4608bb766a70ca12a2142a0e2687813f3a4b9100
Was-Change-Id: I4b2298cf5c3b400e7a1436384653ce01a462a2e0
Was-Change-Id: I4bcc7e07a4f4886c5994d17cbef72ea09eb1be1d
Was-Change-Id: If55182ca29f37f2a783fdb88ba46512944a61c47
Was-Change-Id: I72cdfc6b76bfd9c2832a5d5e5f72c3aa45cf1efe
Was-Change-Id: Ie7088bdbfcae396602b59e2ab07fbfbbb14d96af
Was-Change-Id: I2af9c3964978c842dac8f70ad814adb529dff39f
Was-Change-Id: I0267182fbfa646de40ac62f832e89fbfd8477822
Was-Change-Id: Ifad125815318f07b332c6323feffbd216dad6144
Was-Change-Id: I29f1fa5744659e6095203e860267c6ed02268943
Reviewed-by: Lai Siyao <lai.siyao@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/55474
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>