File owner UID in File Manager

[thiell]

Hello, in OOD file manager, if you click on Show Owner/Mode, it displays numeric UIDs, instead of the user names of the file owner. I wonder if this could be fixed. Thanks!

[treydock]

@thiell If you run ls -la against that directory from the OnDemand node, does it show numeric IDs or names?

[matthu017]

cloudcmd parses the /etc/passwd file and matches it up with the respective UID (using the npm package, nicki). The owners to the respective UIDs are not present in /etc/passwd, hence why it displays UIDs instead of usernames.
This can be solved in several ways:
-The sys admin could add all of these UID-owner pairs to the etc/passwd file. However I'm concerned about data security with this fix.
-A parser could be built on top of existing cloudcmd code specific to each user. Then if users have a shared directory/project/group, something like a shared file in that dir could be used to generate usernames?
-Most people work on independent projects so their username could be read from whoami and $USER
Edit: the bash command id -nu $UID returns the username corresponding to each UID. This is the solution to beat.

[kcgthb]

Mmh, parsing /etc/passwd seems like a recipe for missing most of the uids, these days. All remote directory services will not populate local /etc/passwd files.

What about using getent instead?

[treydock]

-The sys admin could add all of these UID-owner pairs to the etc/passwd file. However I'm concerned about data security with this fix.

There is no security issue with this, that's common practice for defining users, there is nothing sensitive in /etc/passwd. However asking a site to take something like LDAP or AD and populate that in /etc/passwd is not practical. OnDemand should work with users not being in /etc/passwd because common Linux utilities can map users from other sources like SSSD via nsswitch.

[matthu017]

The commands getent passwd $UID | cut -d: -f1 and id -nu $UID both work to get the username and they map those users from sssd

[ericfranz]

This will not be done in time for 1.8 and for the 2.0 release we will replace the Files app. So will keep this slated for 2.0 and revisit when we begin work on that. I think we would want to find a way to get the relevant information in a smarter way. For example, if we must call getent we don't want to do it once for every file we will present in the interface - if all the files in a directory are owned by one user, for example and that directory contains 1000 entries, we only should call getent once, not a 1000 times.

[ericfranz]

@treydock is getpwuid sufficient for this (man 3 getpwuid):

The getpwnam() function returns a pointer to a structure containing the broken-out fields of the record in the password database (e.g., the local password file /etc/passwd, NIS, and LDAP) that matches the username name.

Is there any reason why we couldn't use the passwd struct, or just fallback to uid if the passwd struct is not available.

[treydock]

You could use getpwuid or the Ruby equivalent from Etc library, it will work with SSSD. When I have used Etc module from Ruby it will raise ArgumentError if unable to perform the lookup and populate the necessary data. Falling back to UID is reasonable. Here is some code if this is done in Ruby: https://github.com/treydock/puppet-module-gpfs/blob/master/lib/puppet/provider/gpfs_fileset/shell.rb#L46-L51

[ericfranz]

Fixed in OOD 2.0 using Etc for UID lookup