3

I asked a similar question today, about how to authenticate my server users to a postgres database instead of the /etc/passwd file or LDAP, and I got some useful answers there. I figured out that I have three pieces of my server auth to take care of: logging users in, setting their uid and gids, and giving them sudo access if necessary.

I was able to find NSS and PAM modules for postgres, but no information on how to use a database, especially postgres, for sudo instead of sudoers and sudoers.d. I tried to find a plugin for sudo but it doesn't look like one exists - I only found the one plugin on the sudo website plugin page.

Is it possible to use an external database for sudo?

Community
  • 1
josh
  • 257
  • 2
  • 12
  • Um, you do exactly the same thing! sudo uses pam, of course. – Michael Hampton Nov 15 '13 at 05:29
  • Oops! I don't know why I didn't think about that. Can you give me an example of how I would accomplish this? I would ideally like to use `pam-pgsql` for sshd and sudo, but it seems that `pam-pgsql` is more suited for logging in rather than checking authorization... but I am new to `pam` modules so I think I'm not understanding it fully. – josh Nov 15 '13 at 05:40
  • Do you mean to use the external database to authenticate the user, or to replace the `sudoers` file in clarifying what privileges the user may exert? – MadHatter Nov 15 '13 at 05:59
  • To replace the `sudoers` file. I'll authenticate the user when they login, such as during ssh. – josh Nov 15 '13 at 06:01

2 Answers2

2

Were I in your position I would use LDAP to solve all three of your problems:

  1. Logging users in/out (Authentication).
    pam_ldap/nss_ldap, pam_ldapd, or any number of other options exist here.
    They're all well proven and heavily used (which means OS vendors make sure they work), so why not use them?

  2. Setting their UID and GIDs (Attributes. Also stuff like home directory, shell, etc).
    Already solved by the same tools that solve (1) - the LDAP directory has user and group information in it thanks to the RFC 2307 schema extensions which pretty much every LDAP server supports.

  3. Giving people sudo (A special case of Authorization).
    Sudo can talk to an LDAP directory, and it comes with a schema specification.
    Adding this to your directory is trivial and changes are picked up instantly.

If you have a religious objection to LDAP and insist on managing this information in a SQL database you can use SQL as a back-end for OpenLDAP, but frankly I think that would be Doing It Wrong -- the data is not naturally "relational" and you shouldn't try to force it to be.
If you want to do this because you already have a substantial investment in a SQL-backed user store you might want to consider this as a transitional step toward getting those users into LDAP and converting your other applications to authenticate/authorize against an LDAP directory.

LDAP/RFC 2307 is a really good model for user account management (though by no means perfect - it has a few brain-dead choices I don't agree with).

As a bonus a whole bunch of other things speak LDAP natively (for example Microsoft's Active Directory is just LDAP with some extras hanging off it, and MS supports extending AD with the RFC 2307 schema ; Apache has auth modules which speak LDAP) so by using LDAP you're well on your way to single-sign-on, and can interoperate with Microsoft's products which is a nice capability to have.

You do have two other options, but they're really not attractive IMHO:

  1. Write a sudo plugin to consult the database.
    This has the advantage of being real-time, like using LDAP. You'd need to be a pretty decent coder (or have one available), but if you were to write such a plugin I'm sure you could open-source it and find some folks willing to help with development.

  2. Store your data in the database and sync the servers with a cron job.
    Basically generate a new sudoers file periodically -- really easy to code up, but it's definitely an inelegant hack. The fact that updates don't occur in real time means it's a non-starter in a lot of environments.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
2

The usual way is to treat sudo as what it is, a set of configuration files. Manage them though whatever configuration management you've chosen, let it be chef, puppet, CFengine, subversion, git etc or simply edit them manually.

When the privileges/rules in sudo are given to groups and not individuals, they become pretty static in my experience, the DBA team needs to su - oracle; su - sybase ; /etc/init.d/oracle * ; /etc/init.d/sybase * and what changes most are the members of the DBA team.

Then your sudo management is then reduced to authentication, user and group management. That's where PAM comes in the picture again. Configure PAM to use a centrally managed user database, let it be LDAP, NIS, Active Directory (LDAP + Kerberos), or even a MySQL or Postgresql database. sudo already uses PAM by default.

Now simply manage your user/group database with whatever tools work best.

HBruijn
  • 72,524
  • 21
  • 127
  • 192