Details
Description
It would be useful to allow names to be mapped to projid numbers using the /etc/projid file (projid.5), as is used by the XFS quota utility (xfs_quota.8):
usera:1 userc:3
There should be a new function struct ll_project *llapi_getprjname(const char *name) function that is called by lfs and lctl to read the /etc/projid file and lookup the name and return the projid, while struct ll_project *llapi_getprjid(__u32 prjid) would lookup the numeric project ID and return the name:
struct ll_project {
__u32 lp_projid;
char *lp_name;
};
Returning the struct instead of a single value (name or prjid) allows expanding this interface in the future (e.g. to list which users are allowed to use/change the group, passwords for the group, etc. as with getgrnam(), getgrgid(), getpwnam(), getpwuid()).
It isn't very clear what benefit the /etc/projects file (projects.5) provides, so I'm not yet sure whether we need to implement support for this or not.
This should be available for use by lfs project -p, lfs find -projid, lfs quota -p, lfs setquota -p.
Attachments
Issue Links
- has to be done before
-
LU-18659 add new 'lfs projectadd' command to add project entries to the /etc/projid file
-
- Open
-
-
LU-18638 print project name with 'lfs project'
-
- Open
-
-
-
- Open
-
- is related to
-
-
- Open
-
-
-
- Open
-
-
-
- Resolved
-
- is related to
-
LU-12056 tar doesn't support project id
-
- Resolved
-
-
-
- Open
-
Activity
"Frederick Dilger <fdilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/57836
Subject: LU-13335 utils: allow using uid and gid for prjid
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: dfca145f5da870d205b8a855e3f893625e442820
Attached prototype man page projid.5
to describe the base functionality and limitations.
For the "/etc/passwd" fallback, we've been discussing a few approaches:
- store some directive as a comment in the file, like "# config: projname=passwd" or "# config: projname=group" that would redirect all future projname or projid lookups to use getpwnam()/getpwuid() or getgrnam()/getgrgid() as appropriate to look up the supplied name/ID. This has the advantage that it maintains compatibility with XFS, but means that all of the comment lines need to be parsed.
- store some directive as a "special" entry, like "*:passwd:use passwd entry for projid mapping" or "*:group:use group entry for projid mapping", which simplifies the parsing to some extent, but would likely break compatibility with XFS entries.
Alternately, this could be opt-in on the command-line by specifying a "project name" like "-p u:adilger" or "-p g:adilger" to do a user or group database lookup,
Reviewing the Solaris projects(5) man page I see that it is using project names of the form user.USERNAME and group.GROUPNAME" to identify project names to match the username, but which could also be used in addition to or instead of "u:USERNAME". I'm a bit reluctant to allow '.' in the argument. According to this Serverfault page the use of '.' is normally forbidden in user/group names, but I'd prefer to avoid any unnecessary restrictions if possible.
nathand, native LDAP projid support would require extensions to the glibc /etc/nsswitch and sssd functionality to allow a "project" database lookup, which is mostly out of scope for this feature. It would be useful to develop in the future, as proposed in my previous comment-322655:
It might potentially be useful to push a patch upstream for Linux /etc/nsswitch.conf to add the "project" as a valid database type. Since it is glibc, it may not be as obvious as one would hope (both technically and politically), but maybe just cargo-cult copying of e.g. "passwd" or "group" handling would be enough to start? Adding new getprojnam() and getprojid() calls would be needed also.
In the absence of sssd "project" database functionality, my previous proposal in comment-311464 was to overload the "passwd" database to do network-managed name->ID lookups, since many sites I'm familar with are using PROJID=UID for the user "home/" directories, and some mapping like "PROJID=(UID+1000000)" for "project/" and "PROJID=(UID+2000000)" for "scratch/" or similar:
I've also thought for a while that mapping username:uid to the same projid by default would be very convenient. For example, "lfs project -p adilger -r -s /lustre/home/adilger" with uid=1000 would fall back to use projid=1000 if there is no matching "adilger" entry in /etc/projid. That avoids the need to duplicate the entire /etc/passwd into /etc/projid for the common case where projid=uid, and potentially avoids the need to manage distributing /etc/projid to all of the client nodes since getpwnam() can query the configured network name database sssd (LDAP, AD, etc.) if so configured in /etc/nsswitch.conf.
It is reasonable that this fallback to use the passwd database to do UID->PROJID mapping should be configurable/disabled in /etc/projid, so that this functionality can be avoided if it is undesirable (e.g. there is no consistent UID->PROJID mapping, or network database access from the compute nodes is undesirable, or whatever is the reason as I don't like imposing arbitrary policy on the end user).
Alternately, this could be opt-in by specifying a "project name" like "-p u:adilger" or "-p g:adilger" to do a user or group database lookup, respectively, and use the resulting UID or GID for the PROJID. This puts a bit more burden on the admin to specify the database prefix correctly each time. I don't think it is valid to have a ':' in the username because /etc/passwd already uses this as a field separator, so that shouldn't cause any compatibility issues.
I don't mind having both mechanisms available, and it is up to the admin to use the one that they prefer, since this is only "lfs" internal complexity (and not very much at that), and the filesystem still only sees a single number as the end result.
It would be helpful to be able to extend this to be able to lookup Project ID in external sources such as LDAP.
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/46369/
Subject: LU-13335 ldiskfs: add projid to debug logs
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 6bceb0030d15b70097d75f8da2d373310fe2c658
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/46369
Subject: LU-13335 ldiskfs: add projid to debug logs
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 8092bd00214ae19f87207914feeb97cab7faabbe
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/46144
Subject: LU-13335 utils: allow projid lookup by name
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0ef6dd733f261aa2ce7788f4f0f6b29100f1979d
It might potentially be useful to push a patch upstream for Linux /etc/nsswitch.conf to add the "project" as a valid database type. Since it is glibc, it may not be as obvious as one would hope (both technically and politically), but maybe just cargo-cult copying of e.g. "passwd" or "group" handling would be enough to start? Adding new getprojnam() and getprojid() calls would be needed also.
I've filed LU-18661 to track the enable/disable implicit fallback to username/groupname.