0

I'm working on a home-grown user database tied to a larger sustainment application.

The idea has been floated around to tie our users to system users, creating matching /etc/passwd entries each time a new user is generated in our program. Other interaction such as querying uid/gid for username or vice-versa, verifying filesystem ownership, etc. We've already got standard fields defined like user.uid, user.gid, user.home, internal permissions, etc and just need a way to pass these through to the system.

The trouble is, searching for any info online is a needle in a haystack scenario- I haven't been able to find any standard libraries for user account getters and setters, and I'm starting to wonder if these even exist? Is the right approach here to spawnv useradd? It seems like there must be a better way!

Note that the system this is running on is single use (virtualized), for all intents and purposes.

Final edit: It turns out that the most economical solution is:

useradd -g group -c "firstname lastname" -d /export/home/username -m -s /bin/bash username
Derek_6424246
  • 237
  • 3
  • 12
  • 1
    I doubt it is a good idea to establish a 1:1 relation between db-users and system-users. This binds the db-app tightly to the underlying OS structure which might not be what you really want, at least not on the long run. You might be better off setting up a third (independent) entity doing the authentication which then could be used to authenticate db-user *and/or* OS-users. LDAP might be the tools of choice to do so. – alk Mar 06 '13 at 18:32
  • @OliCharlesworth Linux != Solaris – Kijewski Mar 06 '13 at 18:42
  • @Kay: Fair point! I read too quickly. – Oliver Charlesworth Mar 06 '13 at 18:43
  • This is more appropriate for [alt.se.prog](http://programmers.stackexchange.com) – Cole Tobin Mar 06 '13 at 18:46
  • @ColeJohnson if it is out of scope in SO, then http://unix.stackexchange.com/ would be the appropriate place for that question. – Kijewski Mar 06 '13 at 18:50
  • @Kay but the OP wants to do it from a program he codes, not from a command line. – Cole Tobin Mar 06 '13 at 18:56

2 Answers2

2

Is useradd what you are looking for?

useradd -g group -c "firstname lastname" -d /export/home/username -s /bin/ksh username
mkdir -p /export/home/username
chown username /export/home/username
Kijewski
  • 25,517
  • 12
  • 101
  • 143
  • Using existing OS functions through external calls is a last resort. It would be much better to do this in code. – Derek_6424246 Mar 06 '13 at 18:30
  • 2
    Do not use your own implementation in production code. You _will_ screw you system, that's for sure. – Kijewski Mar 06 '13 at 18:32
  • 1
    @Derek_6424246: Calling other programs is the Unix way of doing things. Doing it this way is highly encouraged and you should do it that way. Doing it in code is the worse solution, actually. – datenwolf Mar 06 '13 at 18:34
  • @datenwolf IIUC, he wants to know if there is a `library` that can. He isn't rolling-his-own. So if the non-existent library is written by the executable developers (Debian devs), there is nothing to worry about – Cole Tobin Mar 06 '13 at 18:49
  • 1
    @ColeJohnson: Technically system level tools *are* libraries, you just use them differently. But there's another reason for doing this using separate program: SUID, which may be neccessary in certain system configuration. You don't want end user programs being SUID. – datenwolf Mar 06 '13 at 18:51
  • @ColeJohnson Exactly- my question could be rephrased "Are there software hooks for account creation?" (and if not, why not? seems like they should exist!) – Derek_6424246 Mar 06 '13 at 18:53
  • @datenwolf SUID? `setuserid`? I'm confused. – Cole Tobin Mar 06 '13 at 18:58
  • 2
    @ColeJohnson: SUID binaries, i.e. programs that are executed with the permissions of the user:group that owns the program executable file. A lot of tools related to user account management are or used to be SUID. /usr/sbin/passwd is one of them: It's SUID root, and if it were not, it could not update the system password database with a new password. – datenwolf Mar 06 '13 at 19:39
  • 2
    @ColeJohnson: Code that's executed SUID is security critical and hence it must be written carefully and with security in mind first and foremost. If there were a library for user management, the program that linked that binary would have to be SUID as well, implying very strong security requirements of the consumer program. Because of this, such kind of library would not be found in any well maintained Unix(-like) system, as such a library would be very dangerous by second degree. – datenwolf Mar 06 '13 at 19:41
  • Well, it turns out there are no sw hooks to do this like I had hoped. I'll have to go with my initial solution (single line version of the answer above): `useradd -g group -c "firstname lastname" -d /export/home/username -m -s /bin/bash username` – Derek_6424246 Mar 06 '13 at 20:49
2

You could make your program into a NIS. Can't help you actually do it, but it might be worth looking at for you.

Added: You might be able to use ldap as well.

But any of those two would mean that you only need to keep the DB up to date. The passwd would take care of itself

fredrik
  • 6,483
  • 3
  • 35
  • 45
  • Given my initial question, this is probably the better answer. However, given the expense of implementing this as a solution (and the relative low priority of the problem) I had to go with external OS calls. – Derek_6424246 Mar 06 '13 at 20:46
  • Understandable. And I won't hold it against you. You're just being a good programmer, lazy by nature. :D – fredrik Mar 06 '13 at 20:48