|
I just wanted to point out and double check if anyone else had similar issues recently.
I frequently build build vm's installing and setting up Jenkins and yesterday came across an issue where some of my jobs then started failing on a new Jenkins setup due to file/folder permissions.
It seemed to mkdir -p commands were setting folders to 750 rather than 755 so some commands run as sudo would make folders as root normally at 755 as 750 then the Jenkins user would not be able to access them. Normally this was never a problem.
Testing on the command line everything appeared fine on the server and umask was set to 022 in /etc/login.defs
Changing to become Jenkins user from root and creating directories showed nothing to be wrong... folders 755 and files 664
Anyway I noticed this...
https://github.com/jenkinsci/jenkins/pull/1397/commits
So the umask value in /etc/defaults/jenkins was being ignored and now is being picked up... so now it is 027
I was just wondering maybe this has broken builds for other people where folders get created as root, or one process happens as root and then the jenkins user tries to read the folder or file?
root@server:# cd /tmp/
root@server:/tmp# mkdir testfolder
root@server:/tmp# chmod 750 testfolder/
root@server:/tmp# su jenkins
jenkins@server:/tmp$ cd testfolder/
bash: cd: testfolder/: Permission denied
jenkins@server:/tmp$ touch testfolder/testfile
touch: cannot touch `testfolder/testfile': Permission denied
Why the need for this umask 027 default?
I am sedding it out of the /etc/default/jenkins when I create my vm and using the system default.
|
