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

User Permissions Wiped After Jenkins Restart

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • core

      See here also: http://stackoverflow.com/questions/27131560/jenkins-user-permissions-wiped-on-restart

      Essentially I can set up security and it works, but after a restart all permissions are wiped:

      1. Downloaded Redhat rpm from Jenkings main site (jenkins-1.590-1.1.noarch.rpm) and installed directly onto server

      2. Jobs can be set up and work fine

      3. Enabled jenkins own DB authentication with matrix permissions

      4. Add myself a user ID and assign full permissions, allowing anonymous 'overall read' (NOTE I have done this with and without setting this anonymous permission and the result is the same)

      5. Save

      6. Restart jenkins

      7. Create an account to link the ID added in #4

      8. All seems fine, permissions are in place and I can do everything I want to

      9. can log out and back in without problem

      10. Restart jenkins

      11. Log back into the account

      12. All permissions are gone and I can't access the system.

      13. If I try to hit a secure page directly I get the message "t143ahe is missing the Overall/Administer permission"

      14. This will happen with all users if I have added more than one.

      The same happens with project based matrix authentication.

      To get get back into Jenkins I have to disable security by deleting config.xml and deleting user folders from the users directory.

      Rightly or wrongly I've marked this as a Blocker as I can't set up CI in my company without this security in place (can't have Joe Bloggs kicking off a production build).

          [JENKINS-25842] User Permissions Wiped After Jenkins Restart

          Daniel Beck added a comment -

          Issue needs instructions how to reproduce it.

          Daniel Beck added a comment - Issue needs instructions how to reproduce it.

          Eli Givoni added a comment -

          Happened to us two times now, no indication in the log.
          We are running the latest LTS 1.580.1.
          Random users are marked as deleted in the 'Project-based Matrix Authorization Strategy' but searching for them in the People tab rediscover the user and resetting his password solve the issue.

          The restart was done after a new plugin installation, by checking the restart checkbox.

          Eli Givoni added a comment - Happened to us two times now, no indication in the log. We are running the latest LTS 1.580.1. Random users are marked as deleted in the 'Project-based Matrix Authorization Strategy' but searching for them in the People tab rediscover the user and resetting his password solve the issue. The restart was done after a new plugin installation, by checking the restart checkbox.

          Daniel Beck added a comment -

          Are you a colleague of Chris, or is this an independent instance?

          Daniel Beck added a comment - Are you a colleague of Chris, or is this an independent instance?

          Chris Parr added a comment -

          Hi,

          To reproduce just follow the steps in the description on a clean install.

          I don't know Eli, but I do have a work around for this. It seems to be either a config persistence issue or an issue with the style of user id (or both).

          1. Make sure user IDs are lower case
          2. After setting up security, go to the general config page and save (even though you don't change anything).

          I picked up these hints from the Jenkins user list. I tried them both at the same time and they gave me a secure working instance. Don't know if perhaps step 1 on it's own would work, but I didn't have time to test on a clean instance.

          Cheers

          Chris

          Chris Parr added a comment - Hi, To reproduce just follow the steps in the description on a clean install. I don't know Eli, but I do have a work around for this. It seems to be either a config persistence issue or an issue with the style of user id (or both). 1. Make sure user IDs are lower case 2. After setting up security, go to the general config page and save (even though you don't change anything). I picked up these hints from the Jenkins user list. I tried them both at the same time and they gave me a secure working instance. Don't know if perhaps step 1 on it's own would work, but I didn't have time to test on a clean instance. Cheers Chris

          Nik San added a comment -

          I'm seeing this too, I've just turned security off because it's a pain trying to fix going through the suggested fix steps without it complaining a user or anonymous doesn't have permissions.

          Nik San added a comment - I'm seeing this too, I've just turned security off because it's a pain trying to fix going through the suggested fix steps without it complaining a user or anonymous doesn't have permissions.

          Harsh Shandilya added a comment -

          Mine is worse, I can't even log in :/

          Harsh Shandilya added a comment - Mine is worse, I can't even log in :/

          Ishaan Gupta added a comment -

          The same is the issue with the latest version of Jenkins. (1.3.8).

          Using Jenkins on Docker and on plugin installation and restart, the LDAP properties get reset to own user database.

          Have to reconfigure the security configurations and also set the file configurations as that also gets reset.

           

          Ishaan Gupta added a comment - The same is the issue with the latest version of Jenkins. (1.3.8). Using Jenkins on Docker and on plugin installation and restart, the LDAP properties get reset to own user database. Have to reconfigure the security configurations and also set the file configurations as that also gets reset.  

          Suganya Ravikumar added a comment -

          We ran into the same issue with Jenkins ver 2.164.2 on Ubuntu. After Jenkins master restart, the user accounts/password/security details were wiped out.

          Suganya Ravikumar added a comment - We ran into the same issue with Jenkins ver 2.164.2 on Ubuntu. After Jenkins master restart, the user accounts/password/security details were wiped out.

          posix phonix added a comment -

          In our case it happened after a reboot + few plugin updates.
          1. we had to disable security as per above suggestions
          2. roll back the upgraded plugins to their previous version
          3. enable security back (at this stage users still not able to login)
          4. reload configuration from disk (it will quick-restart jenkins)
          5. users were able to login again, using their original credentials

          we suspect there was an issue while jenkins was loading config.xml causing it to somehow avoid the users/roles section.

          posix phonix added a comment - In our case it happened after a reboot + few plugin updates. 1. we had to disable security as per above suggestions 2. roll back the upgraded plugins to their previous version 3. enable security back (at this stage users still not able to login) 4. reload configuration from disk (it will quick-restart jenkins) 5. users were able to login again, using their original credentials we suspect there was an issue while jenkins was loading config.xml causing it to somehow avoid the users/roles section.

          Robert Horne added a comment -

           I may have found a solution if you are in a similar edge case to me:

           

          I found that on my instance of Jenkins (running on docker, although I think this is irrelevant) had an initialization script.

          Under the $JEKINS_HOME / init.groovy.d directory: security.groovy.

          This file was forcing a security realm strategy and other security settings like authorization strategy.

           

           

          Perhaps check that out, hope it helps!

          Robert Horne added a comment -  I may have found a solution if you are in a similar edge case to me:   I found that on my instance of Jenkins (running on docker, although I think this is irrelevant) had an initialization script . Under the $JEKINS_HOME  / init.groovy.d directory: security.groovy . This file was forcing a security realm strategy and other security settings like authorization strategy.     Perhaps check that out, hope it helps!

            Unassigned Unassigned
            scribe Chris Parr
            Votes:
            7 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: