Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43386

Not sending mail to user with permission to view

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • email-ext-plugin
    • None
    • Jenkins LTS 2.46.1, EmailExtPlugin 2.57.1, role based matrix used

    Description

      After the latest update with the security patch, no mails sended anymore to "requester" of a job.

      The error message in job console looks like this:
      Not sending mail to user user@mail.com with no permission to view currentJob
      When setting the suggested property 

      -Dhudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ=true

      it works.

       

      The user has overall read permission (matrix based security setup) and for the conrete job the permission:

      Job: View,Discover,Read,Workspace

      Run: Update

      The user has an account (if I click on the user which started the job .. also belongs to this job (can seen in the user view)) and the mail address is correct.

      What permissions or settings are required to avoid this problem? We do not like to have this system property enabled.

      Thanks for the great plugin and support!

      Regards,

      • Thomas

      Attachments

        Issue Links

          Activity

            waffel Thomas Wabner created issue -
            waffel Thomas Wabner added a comment -

            seems this issue is a bit related to JENKINS-43268 .. but also different in error message and setup

            waffel Thomas Wabner added a comment - seems this issue is a bit related to  JENKINS-43268 .. but also different in error message and setup
            waffel Thomas Wabner made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-43268 [ JENKINS-43268 ]

            same issue here, We use the Github OAuth Plugin

            https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+Plugin

            emoshaya_cognitoiq Ebrahim Moshaya added a comment - same issue here, We use the Github OAuth Plugin https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+Plugin
            jglick Jesse Glick added a comment -

            Very likely an issue in git not email-ext, like JENKINS-9016 perhaps.

            jglick Jesse Glick added a comment - Very likely an issue in  git not email-ext , like  JENKINS-9016 perhaps.
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-9016 [ JENKINS-9016 ]
            v2v Victor Martinez made changes -
            Link This issue is duplicated by JENKINS-46292 [ JENKINS-46292 ]
            bednarczyk_9ld Łukasz Bednarczyk made changes -
            Summary Not sending mail to user with no permission to view Not sending mail to user with permission to view

            Issue reproduced here, also using Github OAuth Plugin.

            It seems it is not really related to the email-ext plugin, since it happens with the mailer plugin too.

            Fixed the task summary which suggested that the user without read permission is denied access, whereas the user does have the permission and is denied anyway.

             

            bednarczyk_9ld Łukasz Bednarczyk added a comment - Issue reproduced here, also using Github OAuth Plugin. It seems it is not really related to the email-ext plugin, since it happens with the mailer plugin too. Fixed the task summary which suggested that the user without read permission is denied access, whereas the user does have the permission and is denied anyway.  
            catonyx Todd B added a comment -

            We recently updated from a quite old version (1.6 ish) and this is now happening to us too. We have users with employee numbers and then also vanity e-mails. In the logs, it complains that the vanity e-mails do not have permission to view job. I have tried to artificially give "them" permission and so far no luck. This is using the Roles Based permissions (which seems to work fine) except that only some e-mails are going out.

            catonyx Todd B added a comment - We recently updated from a quite old version (1.6 ish) and this is now happening to us too. We have users with employee numbers and then also vanity e-mails. In the logs, it complains that the vanity e-mails do not have permission to view job. I have tried to artificially give "them" permission and so far no luck. This is using the Roles Based permissions (which seems to work fine) except that only some e-mails are going out.

            catonyx That suggests that the email attached to the jenkins user is not the email it's trying to send to, they must match or it will put them into the no access category. And by jenkins user I mean the one they login to not the fake users you see under the people link that it creates for each seen committer 

            davidvanlaatum David van Laatum added a comment - catonyx That suggests that the email attached to the jenkins user is not the email it's trying to send to, they must match or it will put them into the no access category. And by jenkins user I mean the one they login to not the fake users you see under the people link that it creates for each seen committer 
            catonyx Todd B added a comment -

            davidvanlaatum You are right and that is what is in most logs/consoles. Not sure if I can force this or not. We login with our employee number which is a LDAP server, I think. In our CM tool, we have first.last@company.com. So, then Jenkins seems to find both the CM variation and the number @ company.com. I tried editing some of the "people" to use the other e-mail and so far no luck.

            catonyx Todd B added a comment - davidvanlaatum You are right and that is what is in most logs/consoles. Not sure if I can force this or not. We login with our employee number which is a LDAP server, I think. In our CM tool, we have first.last@company.com. So, then Jenkins seems to find both the CM variation and the number @ company.com. I tried editing some of the "people" to use the other e-mail and so far no luck.

            Not sure if it will just get undone again but users can try login to jenkins clicking their name up in the top right then configure on the left and changing their email

            davidvanlaatum David van Laatum added a comment - Not sure if it will just get undone again but users can try login to jenkins clicking their name up in the top right then configure on the left and changing their email
            catonyx Todd B added a comment -

            After many unsuccessful tries to give "unknown" users read access, I found this is the only way which essentially disables the security. In particular, I used the second one below and e-mail notification seem to be back to our normal. Bummer there isn't a better way. Also, it seems I only needed to do this on the master (which after digging, I found that modifying the jenkins.xml was the easiest way).

             

            If the security fix is undesirable in a particular instance, it can be disabled with either or both of the following two system properties:

            • -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true: send mail to build culprits even if they do not seem to be associated with a valid Jenkins login.
            • -Dhudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ=true: send mail to build culprits associated with a valid Jenkins login even if they would not otherwise have read access to the job.
            catonyx Todd B added a comment - After many unsuccessful tries to give "unknown" users read access, I found this is the only way which essentially disables the security. In particular, I used the second one below and e-mail notification seem to be back to our normal. Bummer there isn't a better way. Also, it seems I only needed to do this on the master (which after digging, I found that modifying the jenkins.xml was the easiest way).   If the security fix is undesirable in a particular instance, it can be disabled with either or both of the following two system properties: -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true: send mail to build culprits even if they do not seem to be associated with a valid Jenkins login. -Dhudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ=true: send mail to build culprits associated with a valid Jenkins login even if they would not otherwise have read access to the job.
            mattdrees Matt Drees added a comment -

            We've run into this too. We're using the " Github Authentication Plugin" and the "GitHub Committer Authorization Strategy". I noticed it appears that email addresses owned by admins (as defined by users listed in the GitHub Authorization Settings->Admin User Names field) are not filtered out. Non-admin jenkins user's email addresses are filtered out with the "Not sending mail to user user@cru.org with no permission to view" message.

             

            So this leads me to hypothesize there's a bug in either the github plugin, or how it is used by other components for authorization decisions.

            mattdrees Matt Drees added a comment - We've run into this too. We're using the " Github Authentication Plugin" and the "GitHub Committer Authorization Strategy". I noticed it appears that email addresses owned by admins (as defined by users listed in the GitHub Authorization Settings->Admin User Names field) are not filtered out. Non-admin jenkins user's email addresses are filtered out with the "Not sending mail to user user@cru.org with no permission to view" message.   So this leads me to hypothesize there's a bug in either the github plugin, or how it is used by other components for authorization decisions.
            sgjenkins Steve Graham added a comment -

            Just updated my Gitlab Oauth settings with a Group name for all users. Works as expected, only authorised users who belong to the group set on Gitlab can log in to Jenkins 

            Unfortunately I also now get the messages 

            Not sending mail to user <username@...> with no permission to view <Jenkins Jobname> 

            If I set Global Security->Gitlab OAuth Settings -> Authenticated Users to allow View Read it works ok.

            if I set the same using the Group Name ist does not work.

            I would rate this as a more serious bug - I will try the workaround mentioned above ( SEND_TO_USERS_WIITHOUT_READ ) - it is a workaround.

            ( I also had to set SEND_TO_UNKNOWN_USERS a long time ago... - also a bug, users are known)

            Jenkins Version 2.176 ( just about to go to 2.177)

            Email Extension plugin  - 2.66

            Gitlab OAuth 1.4

             

            sgjenkins Steve Graham added a comment - Just updated my Gitlab Oauth settings with a Group name for all users. Works as expected, only authorised users who belong to the group set on Gitlab can log in to Jenkins  Unfortunately I also now get the messages  Not sending mail to user <username@...> with no permission to view <Jenkins Jobname>  If I set Global Security->Gitlab OAuth Settings -> Authenticated Users to allow View Read it works ok. if I set the same using the Group Name ist does not work. I would rate this as a more serious bug - I will try the workaround mentioned above ( SEND_TO_USERS_WIITHOUT_READ ) - it is a workaround. ( I also had to set SEND_TO_UNKNOWN_USERS a long time ago... - also a bug, users are known) Jenkins Version 2.176 ( just about to go to 2.177) Email Extension plugin  - 2.66 Gitlab OAuth 1.4  
            dadamssg David Adams added a comment -

            Experiencing similar issues as sgjenkins. Using github oauth client for a github organization and can't get email to send. I've tried checking "Allow sending to unregistered users" with no change. I still get: 

            "Not sending mail to user myemail@gmail.com with no permission to view My Project » my-branch#40An attempt to send an e-mail to empty list of recipients, ignored."

            dadamssg David Adams added a comment - Experiencing similar issues as sgjenkins . Using github oauth client for a github organization and can't get email to send. I've tried checking "Allow sending to unregistered users" with no change. I still get:  "Not sending mail to user myemail@gmail.com with no permission to view My Project » my-branch#40An attempt to send an e-mail to empty list of recipients, ignored."
            slide_o_mix Alex Earl made changes -
            Link This issue is blocked by JENKINS-46292 [ JENKINS-46292 ]
            slide_o_mix Alex Earl made changes -
            Assignee David van Laatum [ davidvanlaatum ] Alex Earl [ slide_o_mix ]
            luckyhorang Hokwang Lee added a comment -

            suffering this problem, one more here.

            luckyhorang Hokwang Lee added a comment - suffering this problem, one more here.
            slide_o_mix Alex Earl made changes -
            Assignee Alex Earl [ slide_o_mix ]

            in this area i am seeing something like this (with some obfuscation):

            {{}}
            Warning: user1@company.com is not a recognized user, but sending mail anyway
            Not sending mail to user user2@company.com with no permission to view PROJECT_repo » task/master/branch_name #3Warning: user3@company.com is not a recognized user, but sending mail anyway
            Sending email to: user1@company.com user3@company.com
            I feel like there should be a line break between "#3" and "Warning".

            used platform is: Jenkins 2.235.5

            alexanderstohr Alexander Stohr added a comment - in this area i am seeing something like this (with some obfuscation): {{}} Warning: user1@company.com is not a recognized user, but sending mail anyway Not sending mail to user user2@company.com with no permission to view PROJECT_repo » task/master/branch_name #3Warning: user3@company.com is not a recognized user, but sending mail anyway Sending email to: user1@company.com user3@company.com I feel like there should be a line break between "#3" and "Warning". used platform is: Jenkins 2.235.5
            warlord Derek Atkins added a comment -

            For what it's worth, I am seeing this same issue after I turned on the Bitbucket OAuth Plugin and enabling the Authorization Matrix.  So I think it's based on the AuthZ matrix and not necessarily the OAuth plugin in use (as it seems that people are seeing this with Github, Gitlab, and Bitbucket OAuth).

            I do NOT have the 'allow any authenticated user read access' because it appears any user with a valid BB account can authenticate, even if they are not a member of my group.

            I'm on Jenkins 2.319.2

            warlord Derek Atkins added a comment - For what it's worth, I am seeing this same issue after I turned on the Bitbucket OAuth Plugin and enabling the Authorization Matrix.  So I think it's based on the AuthZ matrix and not necessarily the OAuth plugin in use (as it seems that people are seeing this with Github, Gitlab, and Bitbucket OAuth). I do NOT have the 'allow any authenticated user read access' because it appears any user with a valid BB account can authenticate, even if they are not a member of my group. I'm on Jenkins 2.319.2

            People

              Unassigned Unassigned
              waffel Thomas Wabner
              Votes:
              18 Vote for this issue
              Watchers:
              31 Start watching this issue

              Dates

                Created:
                Updated: