[ 
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to