Details

    • 10.4.0-1

    Description

      PAM authentication in many cases only works if done by the root user or the user that is authenticating itself.

      For example, to read /etc/shadow one has to be root. unix_chkpwd wrapper, created specifically to loosen this requirement, checks that user name matches the current UID. Google-authenticator PAM module reads the data from ~user/ home directory — again, can be only done as root or that user. And so on.

      A solution to all these problems could be a small setuid wrapper that pam plugin invokes. Perhaps this wrapper should check that it is invoked as mysql user…

      Attachments

        Issue Links

          Activity

            > Perhaps this wrapper should check that it is invoked as mysql user…

            This is an absolute must requirement IMHO to not expose /etc/shadow password information to a random user
            (it is the reason for the UID checks within unix_chkpwd in the first place)

            But all in all I think that pam_unix doesn't work as a general authentication mechanism by design and that no new tools to work around this should be distributed ...

            If /etc/shadow based authentication is a must then explicitly adding user "mysql" the "shadow" group looks like a better approach as it requires explicit admin action ... problem right now though is that this automatically exposes
            shadow contents to LOAD DATA INFILE. MySQL manual states that LOAD DATA INFILE can only read world-readable local files, but this seems to be a mixup - I can only find a check for that in the LOAD_FILE() function implementation which is a totally different beast than LOAD DATA INFILE ... (documentation bug report about that about to be written ...)

            hholzgra Hartmut Holzgraefe added a comment - > Perhaps this wrapper should check that it is invoked as mysql user… This is an absolute must requirement IMHO to not expose /etc/shadow password information to a random user (it is the reason for the UID checks within unix_chkpwd in the first place) But all in all I think that pam_unix doesn't work as a general authentication mechanism by design and that no new tools to work around this should be distributed ... If /etc/shadow based authentication is a must then explicitly adding user "mysql" the "shadow" group looks like a better approach as it requires explicit admin action ... problem right now though is that this automatically exposes shadow contents to LOAD DATA INFILE. MySQL manual states that LOAD DATA INFILE can only read world-readable local files, but this seems to be a mixup - I can only find a check for that in the LOAD_FILE() function implementation which is a totally different beast than LOAD DATA INFILE ... (documentation bug report about that about to be written ...)

            /etc/shadow is just one use case. S/Key stores data in /etc/skeykeys. I've got complains about google-authenticator too. Many other PAM modules store data in $HOME. This setuid wrapper is the only solution I can think of that solves all these issues.

            serg Sergei Golubchik added a comment - /etc/shadow is just one use case. S/Key stores data in /etc/skeykeys . I've got complains about google-authenticator too. Many other PAM modules store data in $HOME . This setuid wrapper is the only solution I can think of that solves all these issues.

            Fixed along with the MDEV-15473

            holyfoot Alexey Botchkov added a comment - Fixed along with the MDEV-15473

            > Fixed along with the MDEV-15473

            Nice.

            chalbersma Christopher Halbersma added a comment - > Fixed along with the MDEV-15473 Nice.

            People

              holyfoot Alexey Botchkov
              serg Sergei Golubchik
              Votes:
              3 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.