Bug 984762 - default mysql user in /etc/passwd has bash shell
default mysql user in /etc/passwd has bash shell
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Honza Horak
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-07-15 18:13 EDT by Justin Buser
Modified: 2013-08-16 08:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 176389
Last Closed: 2013-08-16 08:38:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Justin Buser 2013-07-15 18:13:25 EDT
Why is this still the case? Even if Tom's specious "reasons" for this behavior to exist held any water they are completely irrelevant considering the fact that should an administrator want to login as the mysql user for some asinine reason then they could manually change the login shell to whatever they wanted. 

People expect a reasonable amount of security as a general rule when installing daemons etc... This type of thing is nothing but rookie / bush league ignorance IMO.

+++ This bug was initially created as a clone of Bug #176389 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
Mysql installs its user with a bash shell by default, instead of /sbin/nologin.  The relevant preinstall scriptlet is (from rpm -q --scripts mysql-server):

preinstall scriptlet (using /bin/sh):
/usr/sbin/useradd -M -o -r -d /var/lib/mysql -s /bin/bash \
        -c "MySQL Server" -u 27 mysql > /dev/null 2>&1 || :

For security reasons, I would think that should be -s /sbin/nologin by default.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. yum install mysql-server
2. grep mysql /etc/passwd

Actual Results:  mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash

Expected Results:  mysql:x:27:27:MySQL Server:/var/lib/mysql:/sbin/nologin

Additional info:

I'm no mysql expert.  Perhaps there's a good reason for this behavior, but basic googling did not turn up anything.

--- Additional comment from Tom Lane on 2005-12-21 23:03:32 EST ---

I see no particularly good reason to worry about this.  The mysql account is created with no password, so 
you can't log into it anyway unless root changes that.  It's not unreasonable to want to log into it, so I 
don't quite see the point of putting two roadblocks in the way instead of only one.

--- Additional comment from Mike Rubel on 2005-12-21 23:48:01 EST ---

I know that password is already locked in shadow, but the behavior is still unusual.

Almost all "default" users in /etc/passwd have both password locked in shadow
and their shells set to /sbin/nologin.  Specifically, bin, daemon, adm, lp,
mail, uucp, operator, games, gopher, ftp, nobody, dbus, vcsa, rpm, haldaemon,
pcap, nscd, named, sshd, rpc, mailnull, smmsp, rpcuser, nfsnobody, and ntp all
have this property.  Is logging in as mysql a common or necessary thing to do? 
Wouldn't more-secure-by-default be a better alternative, seeing as this is just
a one-line configuration change?

This is admittedly a long shot, but if a flaw in mysqld allowed an attacker to
write a suitably-permissioned ssh key into /var/lib/mysql/.ssh/authorized_keys
(which mysqld does have access to), then the current configuration allows him to
automatically gain remote shell access, circumventing the locked password.  I've
just verified this by creating the file as mysql on a vanilla FC4 installation.

--- Additional comment from Tom Lane on 2006-01-04 22:14:47 EST ---

Yes, there are good reasons to run shell commands as the mysql user --- to take a common example, 
mysqlhotcopy has to be run as that user (or else as root, which hardly seems better).  I don't find this 
issue serious enough to force people to change their database backup procedures.

The .ssh point might best be addressed by configuring SELinux to disallow the daemon from touching the 
.ssh files.  Offhand I can't think of a case where it would legitimately need to do that (though I might be 
missing something).

--- Additional comment from Robert Scheck on 2007-02-14 10:20:30 EST ---

Tom, you're missing something really important - cases like at CVE-2007-0003 
some weeks ago. There it was possible to login as mysql user and to keep the 
access easily - and the mysql user was the only user where this abuse really 
worked perfect, because of /bin/bash as login shell.

Please re-open!

--- Additional comment from Tom Lane on 2007-02-14 11:18:42 EST ---

The fact remains that a database administrator needs shell access as mysql to do
backups.  I'm not interested in changing this, especially since I see that MySQL
AB's RPMs create the userid with a normal shell too.  If you can convince them
to redesign their database maintenance procedures so that a shell is
unnecessary, then I'll follow suit, but I'm not going to break things on my own
authority just to add one more level of security.

--- Additional comment from Justin Buser on 2013-07-15 17:19:52 EDT ---

(In reply to Tom Lane from comment #1)
> I see no particularly good reason to worry about this.  The mysql account is
> created with no password, so 
> you can't log into it anyway unless root changes that.  It's not
> unreasonable to want to log into it, so I 
> don't quite see the point of putting two roadblocks in the way instead of
> only one.

I know this is closed but I just had to comment on this, all I have to say is WOW, glad this guy isn't responsible for security in any of MY servers :)
Comment 1 Honza Horak 2013-07-18 11:07:21 EDT
It seems to me like a good idea to have user created with nologin by default. However, right now it would make test suite unable to be run from scratch, since it creates some stuff under /usr/share/mysql-test. So, I'll take a look how to make test suite run-able as any user, then we could probably change the default login shell.
Comment 2 Fedora End Of Life 2013-08-01 13:04:42 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 3 Honza Horak 2013-08-07 01:39:13 EDT
Still worth fixing in recent Fedora.
Comment 4 Honza Horak 2013-08-16 08:38:32 EDT
Fixed in Rawhide, so it will make into Fedora 20.

Note You need to log in before you can comment on or make changes to this bug.