[Maria-discuss] Why does local root need a password?
Hello, I’ve submitted a proposal to the MySQL team to allow the system administrator, when logging in via a local socket that indicates reliably that the DB client is the superuser (e.g., SO_PEERCRED in Linux), to not need a password. As implemented, my suggestion allows root to log in as any user. The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data. This will simplify DB administration on several levels, but most conspicuously because a lost DB admin password will no longer necessitate the awkward one-time-init-file recovery method. Would MariaDB be interested in this proposal? -FG
MariaDB already supports authenticating as OS users such as root, when use by UNIX domain sockets for communications: https://mariadb.com/kb/en/library/authentication-plugin-unix-socket/
On Mar 25, 2019, at 6:07 PM, Felipe Gasper <felipe@felipegasper.com> wrote:
Hello,
I’ve submitted a proposal to the MySQL team to allow the system administrator, when logging in via a local socket that indicates reliably that the DB client is the superuser (e.g., SO_PEERCRED in Linux), to not need a password. As implemented, my suggestion allows root to log in as any user.
The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data.
This will simplify DB administration on several levels, but most conspicuously because a lost DB admin password will no longer necessitate the awkward one-time-init-file recovery method.
Would MariaDB be interested in this proposal?
-FG _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
That’s different, I think. That’s for a mapping between system users and dB users. What I’m proposing is specifically for root, to be able to log in as any DB user. -FG
On Mar 25, 2019, at 6:21 PM, Justin Swanhart <greenlion@gmail.com> wrote:
MariaDB already supports authenticating as OS users such as root, when use by UNIX domain sockets for communications: https://mariadb.com/kb/en/library/authentication-plugin-unix-socket/
On Mar 25, 2019, at 6:07 PM, Felipe Gasper <felipe@felipegasper.com> wrote:
Hello,
I’ve submitted a proposal to the MySQL team to allow the system administrator, when logging in via a local socket that indicates reliably that the DB client is the superuser (e.g., SO_PEERCRED in Linux), to not need a password. As implemented, my suggestion allows root to log in as any user.
The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data.
This will simplify DB administration on several levels, but most conspicuously because a lost DB admin password will no longer necessitate the awkward one-time-init-file recovery method.
Would MariaDB be interested in this proposal?
-FG _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
The governance committee would have a fit about that security. That would set up the possibility of the DBA logging in as an application service user or some other user and edit data implicitly implying that the service account or the user has been hacked as the edits came from that user in the audit logs. Yes by nature the DBA is god and this is true in all databases. SOX based users in the US will talk about all the problems they have been dealt with by auditors when addressing compliance. For me, this opens a big can of governance worms. Happy to hear why that's wrong Cheers Peter On Tue, 26 Mar 2019 at 10:02, Felipe Gasper <felipe@felipegasper.com> wrote:
That’s different, I think. That’s for a mapping between system users and dB users.
What I’m proposing is specifically for root, to be able to log in as any DB user.
-FG
On Mar 25, 2019, at 6:21 PM, Justin Swanhart <greenlion@gmail.com> wrote:
MariaDB already supports authenticating as OS users such as root, when use by UNIX domain sockets for communications: https://mariadb.com/kb/en/library/authentication-plugin-unix-socket/
On Mar 25, 2019, at 6:07 PM, Felipe Gasper <felipe@felipegasper.com> wrote:
Hello,
I’ve submitted a proposal to the MySQL team to allow the system administrator, when logging in via a local socket that indicates reliably that the DB client is the superuser (e.g., SO_PEERCRED in Linux), to not need a password. As implemented, my suggestion allows root to log in as any user.
The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data.
This will simplify DB administration on several levels, but most conspicuously because a lost DB admin password will no longer necessitate the awkward one-time-init-file recovery method.
Would MariaDB be interested in this proposal?
-FG _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
-- Peter McLarty Leader and Technologist 0402094238 http://petermclarty.setmore.com/
On Mar 25, 2019, at 9:09 PM, Peter McLarty <peter.mclarty63@gmail.com> wrote:
The governance committee would have a fit about that security. That would set up the possibility of the DBA logging in as an application service user or some other user and edit data implicitly implying that the service account or the user has been hacked as the edits came from that user in the audit logs.
The audit logs … that the admin can falsify anyway? An application service that likely has its credentials stored on the same server over which the admin has total access? User credentials that very likely are stored in ~/.my.cnf?
Yes by nature the DBA is god and this is true in all databases. SOX based users in the US will talk about all the problems they have been dealt with by auditors when addressing compliance.
What I’m getting at is not that “DBA is god” so much as that “sysadmin is god of gods”. The idea of “DBA” just means someone who can do anything at all within the DB. But a local administrator, who can SIGKILL the DB (as opposed to asking the DB to shut itself down), who can edit the actual DB files manually, who can swap out anything for anything else, is another level of privilege. *That* user should have no need for credentials: they are who they say they are by the nature of what a sysadmin is. -FG
the guy with server room key is god of god of god :P Em seg, 25 de mar de 2019 às 22:30, Felipe Gasper <felipe@felipegasper.com> escreveu:
On Mar 25, 2019, at 9:09 PM, Peter McLarty <peter.mclarty63@gmail.com> wrote:
The governance committee would have a fit about that security. That would set up the possibility of the DBA logging in as an application service user or some other user and edit data implicitly implying that the service account or the user has been hacked as the edits came from that user in the audit logs.
The audit logs … that the admin can falsify anyway? An application service that likely has its credentials stored on the same server over which the admin has total access? User credentials that very likely are stored in ~/.my.cnf?
Yes by nature the DBA is god and this is true in all databases. SOX based users in the US will talk about all the problems they have been dealt with by auditors when addressing compliance.
What I’m getting at is not that “DBA is god” so much as that “sysadmin is god of gods”. The idea of “DBA” just means someone who can do anything at all within the DB.
But a local administrator, who can SIGKILL the DB (as opposed to asking the DB to shut itself down), who can edit the actual DB files manually, who can swap out anything for anything else, is another level of privilege. *That* user should have no need for credentials: they are who they say they are by the nature of what a sysadmin is.
-FG _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
-- Roberto Spadim SPAEmpresarial - Software ERP Eng. Automação e Controle
Hi, Felipe! On Mar 25, Felipe Gasper wrote:
Hello,
I’ve submitted a proposal to the MySQL team to allow the system administrator, when logging in via a local socket that indicates reliably that the DB client is the superuser (e.g., SO_PEERCRED in Linux), to not need a password. As implemented, my suggestion allows root to log in as any user.
The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data.
This will simplify DB administration on several levels, but most conspicuously because a lost DB admin password will no longer necessitate the awkward one-time-init-file recovery method.
Would MariaDB be interested in this proposal?
We totally agree with your rationale. This is why MariaDB packages in Debian had password-less root login for a few years now. It caused some complains from users who expected to be able to login as root without sudo, by specifying a password. Other complained that if MariaDB is installed locally, not system-wide, one should not need sudo to login as root (there's a debian bug report about it). These issues were fixed in 10.4. And now in MariaDB-10.4 by default creates two accounts that allow both SO_PEERCRED-based and password-based logins. For the root user and for the owner of the datadir. With the rationale, exactly, that these two local users have access to all the data anyway. It was https://jira.mariadb.org/browse/MDEV-12484 - implemented in 10.4.3. It does not allow root to log in as any user though, only as root. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi,
The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data.
The user that is the manager of the server(root in Linux) is not the owner of the data. So imho we should go exactly the opposite direction, trying to make more complicated, not easier, to just do anything that's not strictly managing the server. Yes he can tamper files but one thing is doing that and another is that any 'root' can read sensitive data, consider also MariaDB supports data at rest encryption with third party external key management system. Best Regards Claudio
On Mar 26, 2019, at 12:03 AM, Claudio Nanni <claudio.nanni@mariadb.com> wrote:
Hi,
The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data.
The user that is the manager of the server(root in Linux) is not the owner of the data. So imho we should go exactly the opposite direction, trying to make more complicated, not easier, to just do anything that's not strictly managing the server. Yes he can tamper files but one thing is doing that and another is that any 'root' can read sensitive data, consider also MariaDB supports data at rest encryption with third party external key management system.
MariaDB already ships a “unix_socket” authn plugin by default. All the admin has to do in order to gain access to a user’s data is to enable that plugin for the user, drop privileges, then log in. Arguably, this is just a default-configuration change that I’m suggesting: configure root@localhost to use unix_socket authn by default (on Linux). -FG
participants (6)
-
Claudio Nanni -
Felipe Gasper -
Justin Swanhart -
Peter McLarty -
Roberto Spadim -
Sergei Golubchik