Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Giving all users database server access by default.

Wonko the Sane (25252) writes | more than 4 years ago

User Journal 3

Especially with KDE applications there is a need for each user on a system to have access to a relational database to get full functionality. Usually this is provided by MySQL. Every database server for linux that I know of has its own concept of usernames and passwords which must be configured seperately from the users on the system because traditionally a database server served clients over the network, not local users.

Especially with KDE applications there is a need for each user on a system to have access to a relational database to get full functionality. Usually this is provided by MySQL. Every database server for linux that I know of has its own concept of usernames and passwords which must be configured seperately from the users on the system because traditionally a database server served clients over the network, not local users.

Is there any way to set up MySQL or a MySQL-compatable database that gets username and password information from PAM and stores data in each user's home directory? This would make database access work just like mail delivery, as long as a user exists in the system and has a ~/.mysql_data directory he or she has full access to any database stored in that directory with no per-user configuration required.

It seems to work for mail, why not for databases also?

cancel ×

3 comments

Sorry! There are no comments related to the filter you selected.

Limitations (1)

Qzukk (229616) | more than 4 years ago | (#32517694)

Postgres has one but it's basically just to check username+password, you have to manually create the matching user account, it won't automatically generate one or anything like that. Furthermore, it won't work with /etc/shadow since postgres doesn't run as root and therefore can't read it. See http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-PAM [postgresql.org]

There's too much internal permission junk that would have to be set up in order for it to all work together automatically (not to mention the whole user vs user@host thing). I assume MySQL decided it wasn't even worth trying. Your best bet would be to have account creation scripts that generate a mysql account and database for the user, then keep the password synchronized using a wrapper to passwd (or hack pam_smbpass.so [samba.org] 's "migrate" mechanism into updating the MySQL password)

Re:Limitations (1)

Wonko the Sane (25252) | more than 4 years ago | (#32518600)

(not to mention the whole user vs user@host thing)

It's ironic that just to get access to the database in the first place you need to break good practices by duplicating information that is conceptually the same. Especially when you're talking about one MySQL server taking care of all the Amarok users on a lan. I'm still the same user no matter which machine I happen to log in from. Why should I need multiple entries in a user table to account for all the possible locations from which I might choose to access the database?

Re:Limitations (1)

Qzukk (229616) | more than 4 years ago | (#32519784)

Can't answer that, but I did think of something that may work. There is a pam module for using mysql for user authentication. I think mysql's users are stored in a table, perhaps you can alter that table to add enough columns to store enough information to replace /etc/passwd, and have PAM read from mysql instead of the other way around (may implode on apps that expect to use /etc/passwd). You still have the issue of user@host, but you could create user and user@localhost entries for each user during signup, and only store the system account information in the "user" record.

Of course, screwing with PAM in general seems to be the quickest way to lock yourself out of the system ;)

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>