I tried SUID by changing permissions to 7750 for the script, but that still does not work.
If you want that to work, you'll likely have to create a compiled program as a wrapper for the script. See perlsec for explanation and sample code. (Also, you probably want permissions 4750 for that binary, not 7750.)
| [reply] |
If the DB connection parameters (account/password) accessible to USERA involve permissions that should not be shared among the other users, the thing to do is to create a separate DB user account for the database / tables / columns in question, tailor the permissions for this new account to be appropriate for those other users (e.g. "select" only, or "select" and "update", or whatever), and provide a config file that they can access to use the connection parameters for this restricted DB account.
From what you've described, it sounds like a database access issue, not a login user account issue, so it should be solved via the database connection accounts with suitable granting of access within the DB, not by a shell-level setuid.
The point is that database user accounts and permissions are separate from shell / login accounts and permissions; a DBA manages the former, and a sysadmin manages the latter. | [reply] |
What OS are you running?
Most, if not all modern Linux distributions do not allow setuid scripts to run.
Wikipedia SETUID
More info regarding setuid scripts, as well as an example c wrapper
setuid c wrapper | [reply] |