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

Debian package sets wrong permissions on /var/lib/hudson/.ssh

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • other
    • None
    • Platform: All, OS: Linux

      The hudson debian package (from deb http://hudson.gotdns.com/debian binary/)
      sets the permissions 770 to /var/lib/hudson. This makes any private ssh keys
      unusable because they need permissions like 700 or even less.

          [JENKINS-4047] Debian package sets wrong permissions on /var/lib/hudson/.ssh

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/www/changelog.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=19872
          Log:
          [FIXED JENKINS-4047] Fixed the permission to 750. I believe go-w is all ssh needs for ancestor directoreis.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=19872 Log: [FIXED JENKINS-4047] Fixed the permission to 750. I believe go-w is all ssh needs for ancestor directoreis.

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/main/debian/hudson.postinst
          http://fisheye4.cenqua.com/changelog/hudson/?cs=19882
          Log:
          JENKINS-4047 forgot to commit the actual change

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/debian/hudson.postinst http://fisheye4.cenqua.com/changelog/hudson/?cs=19882 Log: JENKINS-4047 forgot to commit the actual change

          Unfortunately, 0750 is considered a too-open set of permissions (at least under
          Ubuntu 9.04).

          Here's what SSH man page explains:
          [...] ~/.ssh/identity ~/.ssh/id_dsa ~/.ssh/id_rsa
          Contains the private key for authentication. These files contain sensitive data
          and should be readable by the user but not accessible by others
          (read/write/execute). ssh will simply ignore a private key file if it is
          accessible by others. [...]

          Here's a job output after upgrading Hudson to 1.323 (and former ones):
          [...] A SCM change trigger started this job
          cvs -q -z3 update -PdC -D "Monday, September 7, 2009 11:01:09 AM UTC"
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          Permissions 0750 for '/var/lib/hudson/.ssh/id_rsa' are too open.
          It is recommended that your private key files are NOT accessible by others.
          This private key will be ignored.
          bad permissions: ignore key: /var/lib/hudson/.ssh/id_rsa
          Permission denied, please try again.
          Permission denied, please try again.
          Permission denied (publickey,gssapi-with-mic,password).
          cvs [update aborted]: end of file from server (consult above messages if any)
          FATAL: CVS failed. exit code=1
          Sending e-mails to: john@doe.com
          Finished: FAILURE

          Could you please use 0700 instead of 0750?
          Regards,
          Regis

          Régis Desgroppes added a comment - Unfortunately, 0750 is considered a too-open set of permissions (at least under Ubuntu 9.04). Here's what SSH man page explains: [...] ~/.ssh/identity ~/.ssh/id_dsa ~/.ssh/id_rsa Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute). ssh will simply ignore a private key file if it is accessible by others. [...] Here's a job output after upgrading Hudson to 1.323 (and former ones): [...] A SCM change trigger started this job cvs -q -z3 update -PdC -D "Monday, September 7, 2009 11:01:09 AM UTC" @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0750 for '/var/lib/hudson/.ssh/id_rsa' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /var/lib/hudson/.ssh/id_rsa Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-with-mic,password). cvs [update aborted] : end of file from server (consult above messages if any) FATAL: CVS failed. exit code=1 Sending e-mails to: john@doe.com Finished: FAILURE Could you please use 0700 instead of 0750? Regards, Regis

          Tip for Debian-like GNU/Linux:

          Execute:
          sudo chmod -R 700 /var/lib/hudson/.ssh
          ... each time and just after hudson package is upgraded.

          Or configure ssh so that it doesn't complain if

          Régis

          Régis Desgroppes added a comment - Tip for Debian-like GNU/Linux: Execute: sudo chmod -R 700 /var/lib/hudson/.ssh ... each time and just after hudson package is upgraded. Or configure ssh so that it doesn't complain if Régis

          I propose to change the 'chmod 750' in the .deb to something more reasonable, to
          only chmod the installed files.

          Please do make a difference between files and folders, I would propose to use:

          chmod 750 /var/lib/hudson
          chmod -R u+rwX /var/lib/hudson/*
          chmod -R g+rX /var/lib/hudson/*

          (wow that looks cryptic..)

          Chris lutje Spelberg added a comment - I propose to change the 'chmod 750' in the .deb to something more reasonable, to only chmod the installed files. Please do make a difference between files and folders, I would propose to use: chmod 750 /var/lib/hudson chmod -R u+rwX /var/lib/hudson/* chmod -R g+rX /var/lib/hudson/* (wow that looks cryptic..)

          About the postinst script:
          8< --------------------

          1. Fix permissions on runtime directories/files.
            chown -R hudson:adm /var/run/hudson /var/lib/hudson /var/log/hudson
            chmod -R 750 /var/run/hudson /var/lib/hudson
            chmod 750 /var/log/hudson
                                                • >8
                                                  1. Changing owner to hudson:adm doesn't work for symlinked stuff (for example
                                                  jobs may be stored on a separate volume for backups).
                                                  Therefore, the command should be:
                                                  chown -R -L hudson:adm /var/run/hudson /var/lib/hudson /var/log/hudson
                                                  (-L: traverse every symbolic link to a directory encountered)
                                                  That said, what's the reason why group of hudson files changes at upgrade time
                                                  (nogroup -> adm)? If one needs to alter hudson working area, she can sudo the
                                                  desired command. Or maybe I miss something.

          2. Changing file mode bits recursively starting at /var/lib/hudson is too much
          because one may add custom stuff... such as OpenSSH keys.
          As said, under Debian-based GNU/Linux, OpenSSH client default configuration of
          is to "simply ignore a private key file if it is accessible by others".
          So ideal mode bits for /var/lib/hudson/.ssh/id* are 0600 (0700 makes no sense as
          such, but it's OK if that simplifies the postinst script).
          So they are several ways to address this:

          • leave .ssh untouched, for example:
            find /var/lib/hudson/ | grep -v /var/lib/hudson/.ssh | xargs -n1 chmod 750
          • re-fix .ssh permissions in a second pass:
            chmod -R 750 /var/run/hudson /var/lib/hudson
            ...
            chmod -R 700 /var/lib/hudson/.ssh

          What has to be kept in mind is that identity files must not be world-readable,
          nor even group-readable: only user-readable.

          Régis
          Régis

          Régis Desgroppes added a comment - About the postinst script: 8< -------------------- Fix permissions on runtime directories/files. chown -R hudson:adm /var/run/hudson /var/lib/hudson /var/log/hudson chmod -R 750 /var/run/hudson /var/lib/hudson chmod 750 /var/log/hudson >8 1. Changing owner to hudson:adm doesn't work for symlinked stuff (for example jobs may be stored on a separate volume for backups). Therefore, the command should be: chown -R -L hudson:adm /var/run/hudson /var/lib/hudson /var/log/hudson (-L: traverse every symbolic link to a directory encountered) That said, what's the reason why group of hudson files changes at upgrade time (nogroup -> adm)? If one needs to alter hudson working area, she can sudo the desired command. Or maybe I miss something. 2. Changing file mode bits recursively starting at /var/lib/hudson is too much because one may add custom stuff... such as OpenSSH keys. As said, under Debian-based GNU/Linux, OpenSSH client default configuration of is to "simply ignore a private key file if it is accessible by others". So ideal mode bits for /var/lib/hudson/.ssh/id* are 0600 (0700 makes no sense as such, but it's OK if that simplifies the postinst script). So they are several ways to address this: leave .ssh untouched, for example: find /var/lib/hudson/ | grep -v /var/lib/hudson/.ssh | xargs -n1 chmod 750 re-fix .ssh permissions in a second pass: chmod -R 750 /var/run/hudson /var/lib/hudson ... chmod -R 700 /var/lib/hudson/.ssh What has to be kept in mind is that identity files must not be world-readable, nor even group-readable: only user-readable. Régis Régis

          uncletall added a comment -

          It seems like a simple fix.
          I was suprised to see all my builds fail while I previously fixed the .ssh issue
          manually. Then I figured it must be after I upgraded husdon during a general
          system upgrade (apt-get upgrade).

          I think I would prefer the hudson upgrade not to change any of the permissions
          after the initial install. To be more tranparent I would suggest setting
          permissions during the first install and leaving them alone during upgrades.

          uncletall added a comment - It seems like a simple fix. I was suprised to see all my builds fail while I previously fixed the .ssh issue manually. Then I figured it must be after I upgraded husdon during a general system upgrade (apt-get upgrade). I think I would prefer the hudson upgrade not to change any of the permissions after the initial install. To be more tranparent I would suggest setting permissions during the first install and leaving them alone during upgrades.

          ahochsteger added a comment -

          Please have a look at JENKINS-5112, which maybe related and therefore should be taken into account.

          Thanks,

          Andreas

          ahochsteger added a comment - Please have a look at JENKINS-5112 , which maybe related and therefore should be taken into account. Thanks, Andreas

          ashlux added a comment -

          I've worked up a possible solution for this and and JENKINS-5112.

          I've chosen to go a little beyond both of these issues and exclude changing the owner of jobs too for performance reasons as well as some jobs might change mode/owner of files and we'd be undoing that work on upgrades (yuck).

          ashlux added a comment - I've worked up a possible solution for this and and JENKINS-5112 . I've chosen to go a little beyond both of these issues and exclude changing the owner of jobs too for performance reasons as well as some jobs might change mode/owner of files and we'd be undoing that work on upgrades (yuck).

          Code changed in hudson
          User: : ashlux
          Path:
          trunk/hudson/main/debian/hudson.postinst
          http://fisheye4.cenqua.com/changelog/hudson/?cs=25795
          Log:
          [FIXED JENKINS-5112] [FIXED JENKINS-4047] Leave permissions and owner of the jobs and .ssh directory alone.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : ashlux Path: trunk/hudson/main/debian/hudson.postinst http://fisheye4.cenqua.com/changelog/hudson/?cs=25795 Log: [FIXED JENKINS-5112] [FIXED JENKINS-4047] Leave permissions and owner of the jobs and .ssh directory alone.

          ashlux added a comment -

          Fix committed for 1.342.

          ashlux added a comment - Fix committed for 1.342.

          ahochsteger added a comment -

          I just upgraded from 1.342 to 1.343 and found a build failing afterwards which launched Xvnc.
          After investigation I found out that the permission of the file /var/lib/hudson/.vnc/passwd has been changed causing Xvnc fail to start.
          The permissions should be 600 but they were 750 after upgrading.

          Besides the permissions and ownerships of the installed tools (different JDK and Maven versions) were also touched unneccessarily.

          Since /var/lib/hudson is the home directory of the user 'hudson' there are many files and directories created which belong to the tools which are started as part of the build.

          IMHO the Debian Package shouldn't mess with the ownerships and permissions of files/directories which are not part of the hudson package at all.

          As I see it, the following lines from version 1.343 of the postinst script perform recursive operations:
          find /var/lib/hudson -path "jobs" -prune -o -path ".ssh" -prune -o -exec chmod 750 {} +
          chown -R hudson:adm /var/run/hudson /var/log/hudson
          find /var/lib/hudson -path "*jobs" -prune -o -exec chown hudson:adm {} +
          chmod -R 750 /var/run/hudson

          No matter which directories or files are excluded (see jobs and .ssh for examples above), there will always be some more which are missing ...

          I'd suggest to take an alternative approach.
          What's the root cause to fix the permissions all the time anyway?

          Therefore I'm reopening the issue ...

          ahochsteger added a comment - I just upgraded from 1.342 to 1.343 and found a build failing afterwards which launched Xvnc. After investigation I found out that the permission of the file /var/lib/hudson/.vnc/passwd has been changed causing Xvnc fail to start. The permissions should be 600 but they were 750 after upgrading. Besides the permissions and ownerships of the installed tools (different JDK and Maven versions) were also touched unneccessarily. Since /var/lib/hudson is the home directory of the user 'hudson' there are many files and directories created which belong to the tools which are started as part of the build. IMHO the Debian Package shouldn't mess with the ownerships and permissions of files/directories which are not part of the hudson package at all. As I see it, the following lines from version 1.343 of the postinst script perform recursive operations: find /var/lib/hudson -path " jobs" -prune -o -path " .ssh" -prune -o -exec chmod 750 {} + chown -R hudson:adm /var/run/hudson /var/log/hudson find /var/lib/hudson -path "*jobs" -prune -o -exec chown hudson:adm {} + chmod -R 750 /var/run/hudson No matter which directories or files are excluded (see jobs and .ssh for examples above), there will always be some more which are missing ... I'd suggest to take an alternative approach. What's the root cause to fix the permissions all the time anyway? Therefore I'm reopening the issue ...

          andisch added a comment - - edited

          Also see issue JENKINS-5771
          Maybe it's really the best and easiest solution to don't touch permission after upgrade.

          andisch added a comment - - edited Also see issue JENKINS-5771 Maybe it's really the best and easiest solution to don't touch permission after upgrade.

          mehow added a comment -

          Another file that shouldn't be touched is .netrc. From man netrc:

          Note that if this token is present in the .netrc file for any user other than anonymous, ftp will abort the auto-login process if the .netrc is readable by anyone besides the user.

          mehow added a comment - Another file that shouldn't be touched is .netrc . From man netrc : Note that if this token is present in the .netrc file for any user other than anonymous, ftp will abort the auto-login process if the .netrc is readable by anyone besides the user.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/debian/dirs
          debian/debian/jenkins.postinst
          http://jenkins-ci.org/commit/core/22187541978e62e16140cf26f3bfc400941cbee1
          Log:
          [FIXED JENKINS-4047] don't mess with file permissions

          ahochsteger asks 'why do we mess with file permissions anyway?' and he's
          right! I digged the history but couldn't find why we do it.

          I think we should just set the permissions of the top-level directories,
          but leave the other file permissions as-is.

          In addition,

          • I see no point in touching usr/bin usr/sbin.
            perhaps C&P mistake from some samples?
          • Don't touch /var/lib/hudson if .for-jenkins is present,
            so that people using the hudson user can keep upgrading new
            versions of jenkins and run it as hudson
          • /var/run/hudson contains no important information,
            so no need to bring it over to /var/run/jenkins

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/debian/dirs debian/debian/jenkins.postinst http://jenkins-ci.org/commit/core/22187541978e62e16140cf26f3bfc400941cbee1 Log: [FIXED JENKINS-4047] don't mess with file permissions ahochsteger asks 'why do we mess with file permissions anyway?' and he's right! I digged the history but couldn't find why we do it. I think we should just set the permissions of the top-level directories, but leave the other file permissions as-is. In addition, I see no point in touching usr/bin usr/sbin. perhaps C&P mistake from some samples? Don't touch /var/lib/hudson if .for-jenkins is present, so that people using the hudson user can keep upgrading new versions of jenkins and run it as hudson /var/run/hudson contains no important information, so no need to bring it over to /var/run/jenkins

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          http://jenkins-ci.org/commit/core/129adcea9568b11447725dd276ca99255e69a179
          Log:
          Recording JENKINS-4047 toward 1.397

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html http://jenkins-ci.org/commit/core/129adcea9568b11447725dd276ca99255e69a179 Log: Recording JENKINS-4047 toward 1.397

          Ferenc Kovacs added a comment -

          there is no group with the name admin on debian(should be adm), hence the installation fails.

          Ferenc Kovacs added a comment - there is no group with the name admin on debian(should be adm), hence the installation fails.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/debian/jenkins.postinst
          http://jenkins-ci.org/commit/core/9d250135e85d6662ff7a53d69424fac0c080b1da
          Log:
          [FIXED JENKINS-4047] not admin, should be adm.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/debian/jenkins.postinst http://jenkins-ci.org/commit/core/9d250135e85d6662ff7a53d69424fac0c080b1da Log: [FIXED JENKINS-4047] not admin, should be adm.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/debian/control
          debian/debian/jenkins.postinst
          http://jenkins-ci.org/commit/core/7219e3af4b8e1f464cb034546cdb16059f1ec4d3
          Log:
          Merge branch 'rc'

          • rc:
            Fix dependency on Java2 runtime for both Debian and Ubuntu
            [FIXED JENKINS-4047] not admin, should be adm.
            [FIXED JENKINS-8159] back to java-runtime

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/debian/control debian/debian/jenkins.postinst http://jenkins-ci.org/commit/core/7219e3af4b8e1f464cb034546cdb16059f1ec4d3 Log: Merge branch 'rc' rc: Fix dependency on Java2 runtime for both Debian and Ubuntu [FIXED JENKINS-4047] not admin, should be adm. [FIXED JENKINS-8159] back to java-runtime

          dogfood added a comment -

          Integrated in jenkins_main_trunk #511
          [FIXED JENKINS-4047] not admin, should be adm.

          Kohsuke Kawaguchi :
          Files :

          • debian/debian/jenkins.postinst

          dogfood added a comment - Integrated in jenkins_main_trunk #511 [FIXED JENKINS-4047] not admin, should be adm. Kohsuke Kawaguchi : Files : debian/debian/jenkins.postinst

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/dirs
          debian/jenkins.postinst
          http://jenkins-ci.org/commit/packaging/214311c32a2aff19e83fe54b0b519b1137de0962
          Log:
          [FIXED JENKINS-4047] don't mess with file permissions

          ahochsteger asks 'why do we mess with file permissions anyway?' and he's
          right! I digged the history but couldn't find why we do it.

          I think we should just set the permissions of the top-level directories,
          but leave the other file permissions as-is.

          In addition,

          • I see no point in touching usr/bin usr/sbin.
            perhaps C&P mistake from some samples?
          • Don't touch /var/lib/hudson if .for-jenkins is present,
            so that people using the hudson user can keep upgrading new
            versions of jenkins and run it as hudson
          • /var/run/hudson contains no important information,
            so no need to bring it over to /var/run/jenkins

          Originally-From: jenkins-ci.org/commit/core/22187541978e62e16140cf26f3bfc400941cbee1

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/dirs debian/jenkins.postinst http://jenkins-ci.org/commit/packaging/214311c32a2aff19e83fe54b0b519b1137de0962 Log: [FIXED JENKINS-4047] don't mess with file permissions ahochsteger asks 'why do we mess with file permissions anyway?' and he's right! I digged the history but couldn't find why we do it. I think we should just set the permissions of the top-level directories, but leave the other file permissions as-is. In addition, I see no point in touching usr/bin usr/sbin. perhaps C&P mistake from some samples? Don't touch /var/lib/hudson if .for-jenkins is present, so that people using the hudson user can keep upgrading new versions of jenkins and run it as hudson /var/run/hudson contains no important information, so no need to bring it over to /var/run/jenkins Originally-From: jenkins-ci.org/commit/core/22187541978e62e16140cf26f3bfc400941cbee1

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          debian/jenkins.postinst
          http://jenkins-ci.org/commit/packaging/179fc47d1cf5a6698f8652161c9e4687f25c4fc0
          Log:
          [FIXED JENKINS-4047] not admin, should be adm.

          Originally-From: jenkins-ci.org/commit/core/9d250135e85d6662ff7a53d69424fac0c080b1da

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: debian/jenkins.postinst http://jenkins-ci.org/commit/packaging/179fc47d1cf5a6698f8652161c9e4687f25c4fc0 Log: [FIXED JENKINS-4047] not admin, should be adm. Originally-From: jenkins-ci.org/commit/core/9d250135e85d6662ff7a53d69424fac0c080b1da

            Unassigned Unassigned
            chrisspelberg Chris lutje Spelberg
            Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: