Bug 176389
| Summary: | default mysql user in /etc/passwd has bash shell | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mike Rubel <mrubel> | |
| Component: | mysql | Assignee: | Tom Lane <tgl> | |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 4 | CC: | art.home, byte, hhorak, junk, redhat-bugzilla | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 984762 (view as bug list) | Environment: | ||
| Last Closed: | 2006-01-05 03:14:47 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
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 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. 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). 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! 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. (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 :) Given the recent shellshock debacle, IMHO this should at least be changed to /bin/dash (or /bin/sh - are RedHat ever going to follow Debian's lead and change /bin/sh to be dash?) (In reply to Art O Cathain from comment #7) > Given the recent shellshock debacle, IMHO this should at least be changed to > /bin/dash (or /bin/sh - are RedHat ever going to follow Debian's lead and > change /bin/sh to be dash?) Feel free to join the discussion: https://lists.fedoraproject.org/pipermail/devel/2014-October/202876.html Anyway, since RHEL-7 mysql user has had /bin/nologin as default shell. |
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): mysql-server-4.1.16-1.FC4.1 How reproducible: Always 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.