In Windows, we can use GetUserName() function ( http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx ), NetUserGetInfo() function ( http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx ), to get the username and account information such as account type (administrator, guest, normal user), last logon time, number of seconds since last password change, and a lot more information.

How can we do the same thing in Linux, by using either C or C++?

NetUserGetInfo() function in Windows not only can get user information from local computer, but also remote server. Can we do this in Linux also?

Once you get to system-oriented aspects such as user information and passwords, you won't find direct equivalents between Windows and Linux.

Linux is more 'file' oriented when it comes to storing such information.

User login information is stored in utmp and its variants, and is accessible using calls such as the getutxent family.

Password and group information is stored in /etc/passwd, /etc/shadow, and /etc/groups. This is also accessible through libraries, or directly. Linux doesn't have privileged accounts (except the superuser), but groups are used to provide common access to various files and devices. For installations which also include access control systems (such as SELinux), there are more fine-grained ways to control privilege context, and you would use the functions from that system to report on such context.

Rather than try to find an equivalent to the Windows function, you will have to define what it is you want to do specifically.

When it comes to remote systems, the method of accessing such information depends on the type of directory services being used across the network.

1 members found this post helpful.

Get the username that user used to run the application, then based on the username, find all the account information of that username, including but not limited to user's home directory, user's full name, account expiry date, the period of time since last password change, logon hours, groups that the username belongs to, etc and more, just every user information that stored by linux.

I do these for learning purpose.

getpwent(3) could be useful

To find out the user ID, use getuid() (see man 2 getuid for details). If you want to, you can use getgid() (see man 2 getgid) to find out the group ID, and getgroups() (see man 2 getgroups) to find out the supplemental group IDs of the user running the application.

You can then use getpwuid() (see man 2 getpwuid ) to obtain the basic information about the user, including home directory, full name, and preferred shell. You can use the matching getgrgid() (see man 2 getgrgid) to find out the name and members of each group ID.

This covers all users, not just local user accounts. What neonsignal said is only true for cases where the users are locally defined; if using LDAP for example, the local user and group files typically contain just system accounts, no real users at all. Name Service Switch (NSS) and Pluggable Authentication Modules (PAM) are tied into the above functions, so that when a remote user database is used, they automagically query also the remote databases correctly.

Password change information is privileged. In some cases you can find out the last date the user changed the password by executing chage -l username (which by the way will only work if you are superuser, or username is the current user's username), but that information is not always available -- for example, when using LDAP. (The chage utility is privileged, so you do need to call it as an external program.)

Login information can be obtained using getutxent() or getutxid() functions (see man 3 getutxent for details). However, it does not always contain e.g. X sessions. (On Xubuntu 11.10 at least, X sessions do not show up at all -- a bug, I think.)

If I may, I would recommend pausing for a moment, and reconsidering why you need to collect all that information about the user. I personally find it suspicious that you wish to find out everything about the user running the program -- are you perhaps sending that information to your own servers?

1 members found this post helpful.