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

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

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

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.

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

Thanks,

Andreas

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.

Fix committed for 1.342.

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 ...

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

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

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

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.

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

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

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