You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksandr Yatskin (JIRA)" <ji...@apache.org> on 2019/08/13 06:24:00 UTC
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start
with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905863#comment-16905863 ]
Aleksandr Yatskin edited comment on CASSANDRA-15273 at 8/13/19 6:23 AM:
------------------------------------------------------------------------
The cassandra starts, but the systemd cannot control it. The cause is that when the cassandra starts, the old initialization SysV script is used, in which it is obviously impossible to specify the user and group to start the service.
It's about user/group options for systemd:
-----------------
_[Service]_
_User=cassandra_
_Group=cassandra_
-----------------
But since the process pid is created with the permissions of the cassandra user, and the user and group are not specified in the initialization script, the systemd consider that it uses the root to start the service (by default) and does not allow creating the pid with cassandra user permissions.
------------------
_systemd[1]: New main PID 2545 does not belong to service, and PID file is not owned by root. Refusing._
------------------
More details in CVE-2018-16888 ([https://access.redhat.com/security/cve/cve-2018-16888])
------------------
_It was discovered systemd does not correctly check the content of PIDFile files before using it to kill processes. When a service is run from an unprivileged user (e.g. User field set in the service file), a local attacker who is able to write to the PIDFile of the mentioned service may use this flaw to trick systemd into killing other services and/or privileged processes._
------------------
was (Author: aleksandr yatskin):
The cassandra starts, but the systemd cannot control it. The cause is that when the cassandra starts, the old initialization SysV script is used, in which it is obviously impossible to specify the user and group to start the service.
It's about user/group options for systemd:
-----------------
_[Service]_
_User=cassandra_
_Group=cassandra_
-----------------
But since the process pid is created with the permissions of the cassandra user, and the user and group are not specified in the initialization script,
the systemd consider that it uses the root to start the service (by default) and does not allow creating the pid with cassandra user permissions.
------------------
_systemd[1]: New main PID 2545 does not belong to service, and PID file is not owned by root. Refusing._
------------------
More details in CVE-2018-16888 ([https://access.redhat.com/security/cve/cve-2018-16888])
------------------
_It was discovered systemd does not correctly check the content of PIDFile files before using it to kill processes. When a service is run from an unprivileged user (e.g. User field set in the service file), a local attacker who is able to write to the PIDFile of the mentioned service may use this flaw to trick systemd into killing other services and/or privileged processes._
------------------
> cassandra does not start with new systemd version
> -------------------------------------------------
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Reporter: Aleksandr Yatskin
> Priority: Normal
>
> After update systemd with fixed vulnerability https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---------------------------------------------------------------
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, status=0/SUCCESS)
> Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, status=0/SUCCESS)
> Main PID: 1884 (code=exited, status=143)
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service entered failed state.
> Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed.
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed storage system for structured data...
> Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none
> Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK
> Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not belong to service, and PID file is not owned by root. Refusing.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not belong to service, and PID file is not owned by root. Refusing.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: distributed storage system for structured data.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service entered failed state.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org