Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-10767

/tmp/wsrep_recovery.${RANDOM} file created in unallowed SELinux context

Details

    • 10.1.22

    Description

      A user reported the following error in /var/log/audit/audit.log when trying to start a cluster node:

      type=AVC msg=audit(1473264262.081:132): avc: denied { open } for pid=11191 comm="mysqld" path="/tmp/wsrep_recovery.mx7VGR" dev="dm-1" ino=101950206 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file
      

      This user fixed it with the following addition to their SELinux policy:

      allow mysqld_t initrc_tmp_t:file open;
      

      Should this file actually be created in the mysqld_tmp_t context, or should we modify our SELinux policy to allow access to files in the initrc_tmp_t context?

      Attachments

        Issue Links

          Activity

            elenst Elena Stepanova added a comment - - edited

            Looks similar to MDEV-10753.
            svoj, FYI.

            elenst Elena Stepanova added a comment - - edited Looks similar to MDEV-10753 . svoj , FYI.
            danblack Daniel Black added a comment -

            perhaps setting TMPDIR to /var/run/mysql

            danblack Daniel Black added a comment - perhaps setting TMPDIR to /var/run/mysql
            sachin.setiya.007 Sachin Setiya (Inactive) added a comment - http://lists.askmonty.org/pipermail/commits/2017-September/011456.html

            ok to push

            serg Sergei Golubchik added a comment - ok to push
            hhorak Honza Horak added a comment -

            I'm puzzled here – from description it seems like writing to /tmp/wsrep_recovery.XXXXXX is not what we need, because of the SELinux. Yet it is the current implementation. I'm asking because I indeed see SELinux AVC on RHEL 6 with version 10.1.29.
            It's also not clear to me what was wrong about original location $DATADIR/wsrep_recovery.XXXXXX. Can somebody explain to me, please?

            hhorak Honza Horak added a comment - I'm puzzled here – from description it seems like writing to /tmp/wsrep_recovery.XXXXXX is not what we need, because of the SELinux. Yet it is the current implementation. I'm asking because I indeed see SELinux AVC on RHEL 6 with version 10.1.29. It's also not clear to me what was wrong about original location $DATADIR/wsrep_recovery.XXXXXX . Can somebody explain to me, please?
            anikitin Andrii Nikitin (Inactive) added a comment - - edited

            hhorak In my understanding SELinux complains if mysqld is writing to /tmp ; after the patch it is mysqld_safe and galera_recovery scripts which use /tmp directly and SELinux should be OK with that. (because those scripts usually started by privileged user, while 'mysqld' process is started with context of 'mysql' user)

            anikitin Andrii Nikitin (Inactive) added a comment - - edited hhorak In my understanding SELinux complains if mysqld is writing to /tmp ; after the patch it is mysqld_safe and galera_recovery scripts which use /tmp directly and SELinux should be OK with that. (because those scripts usually started by privileged user, while 'mysqld' process is started with context of 'mysql' user)
            serg Sergei Golubchik added a comment - - edited

            hhorak using $DATADIR/wsrep_recovery.XXXXXX works too. We just didn't want different scripts to use different solutions for the same problem. (And I hope we'll be able to remove the duplicate code and have only one copy of it)

            serg Sergei Golubchik added a comment - - edited hhorak using $DATADIR/wsrep_recovery.XXXXXX works too. We just didn't want different scripts to use different solutions for the same problem. (And I hope we'll be able to remove the duplicate code and have only one copy of it)

            People

              sachin.setiya.007 Sachin Setiya (Inactive)
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.