Question on file owner name representation

Hi All,

I came across a situation where i saw a directory name given below:

 
drwxrwxrwx 5 121973 staff 8192 Apr 26 23:47 arunpr 

Just for your info:

  1. All our application user ids are LDAP.
  2. Hence we will not see any details of user in /etc/passwd file and i believe this could not be the reason since other directories and user/owner names a re properly displayed.

My question here is: how/when/why the numbers comes in place instead of user/owner name.

Thanks a lot in advance!

It's quite possible to have files belonging to users or groups with no corresponding entry in /etc/passwd or /etc/group, nothing prevents it. Anything with sufficient privileges can create files belonging to any ID and group whether represented by anything in passwd or group or not; those only control login permissions through the traditional login system.

touch this ; sudo chown 9999 this

All users and groups are just numbers anyway. If ls doesn't find matching entries in passwd and/or group it will just display numbers. As long as whatever login manager involved sets correct access permissions on login based on the relevant user and group numbers, and the numbers used internally and externally don't overlap, things can be kept consistent without knowing all names locally.

Hi Corona688,

Thanks for the information!
As i said in my earlier note, all of the application users are maintained through LDAP. Since LDAP no users information are maintained in /etc/passwd file. However, if i create a file or diectory and it is having my name(owner name) and all other settings as normal. Almost all users have proper info on their files/dirs. Only few users having numbers as per my example and they are also LDAP.

Please clarify me and let me know if you need any other info from my end to clarify me.

Thanks a lot for your valuable time!

I had come across similar senario , where the use is removed from the server but the directory owned by the user exists.

In this case i had seen the number instead of username.

Hi,

Thanks for the info!
I thought the same but in my case, all user s are LDAP and not maintained locally. So how system determines that this user has been deleted and let represent the userid as number. And for your information, still many user directories/files are showing properly with userid/owner name in its properties.

Thanks a lot for your time! Please advise.

It's abstracted behind the getpwent() call and its related calls, looks like:

GETPWENT(3)                Linux Programmer's Manual               GETPWENT(3)



NAME
       getpwent, setpwent, endpwent - get password file entry

SYNOPSIS
       #include <sys/types.h>
       #include <pwd.h>

       struct passwd *getpwent(void);

       void setpwent(void);

       void endpwent(void);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       getpwent(), setpwent(), endpwent(): _BSD_SOURCE || _SVID_SOURCE ||
       _XOPEN_SOURCE > = 500

DESCRIPTION
       The getpwent() function returns a pointer to a structure containing the
       broken-out  fields  of  a  record from the password database (e.g., the
       local password file /etc/passwd, NIS, and LDAP).  The first time it  is
       called  it  returns  the first entry; thereafter, it returns successive
       entries.

...

So ls doesn't reach in and grab login names from /etc/passwd manually, it just calls getpwent() from glibc, which is capable of getting login info from any valid sources. Finding no corresponding UID in either, ls just prints the UID/GID.

Didn't know getpwent() did that. That's a pretty good reason to use these functions instead of just parsing /etc/passwd yourself!

Thanks a lot for providing more background!

It seems the above is related to Linux anyways i believe thats a not a big deal here.
I am worried about why the ls is not listing the user name for specific ID alone and returns the user name for other files/directories successfully or why the getpwent() fails to retrieve this alone.

Again, all user id's are LDAP sourced.

Please advise.