script file operation gets "permission denied" error

Beeblebrox

Beeblebrox

Script I'm working on has this code bit, which fails with "Permission denied" message:
Code: 
: ${jenkins_user="jenkins-builder"}
: ${jenkins_group="jenkins"}
	......
if [ ! -f "${jenkins_log_file}" ]; then
touch "${jenkins_log_file}"
chown "${jenkins_user}:${jenkins_group}" "${jenkins_log_file}"
chmod 640 "${jenkins_log_file}"
The code works if the target folder permission is set as "777", but fails for regular "755". How can I debug this error?
 
For 755 permissions of the target directory, only the user (owner) or root would be allowed to execute touch/chown/chmod. Most probably, the user running the script is different from the dir-owner.
 
Beeblebrox said:
How can I debug this error?
Click to expand...

Simulate the script commands manually:

# sudo -u jenkins-builder touch /path/to/the/jenkins/logs/testfile
# sudo -u jenkins-builder chown jenkins-builder:jenkins /path/to/the/jenkins/logs/testfile
# sudo -u jenkins-builder chmod 640 /path/to/the/jenkins/logs/testfile
 
Manual execution works fine.
User jenkins:jenkins is a no-login account, while user jenkins-builder:jenkins is an account which can login. Before trying your way, I had also manually tried file operations before by loging-in as jenkins-builder.

EDIT: The folder in question is on an NSF-mounted drive and I tried the operations on the NFS-client.
 
You never mentioned (explicitly nor implicitly) a user jenkins, my impression was that the user running the script is jenkins-builder belonging to the group jenkins. In the given scenario a user jenkins would not have the rights to change something in
Code: 
drwxr-xr-x  2 jenkins-builder  jenkins   5 Mar  9 14:39 logs

Even not, if it also belongs to the group jenkins. Only user jenkins-builder has write permissions.
 
The script calls jenkins-builder as the user:
Code: 
${jenkins_user="jenkins-builder"}
The extra info was maybe unnecessary blurb, but I was just trying to give the full picture.
 
OK, the shell variable jenkins_user is set to jenkins-builder, if it was not before set to anything else. Anyway, this alone does not change the effective user running the script and executing any subsequent commands.

So the basic question is, who is the effective user, and does he have write permissions to the logs directory? - most probably not!
 
There's some kind of odd user-id mis-match going on here. After rebooting the client node/slave (it's diskless, pxe booting from host) and changing the log folder in the script to the "777" enabled folder, I got this error:
Code: 
chown: /path/node.log: Operation not permitted
Looking at the logfile created by script:
Code: 
rw-r-----  1 4294967294       jenkins      0 Mar  9 16:07 node.log
so user jenkins-builder gets this long user-id number. But both host & slave show
Code: 
id jenkins-builder
uid=1003(jenkins-builder) gid=818(jenkins) groups=818(jenkins)

EDIT: The script starts fine from host machine - no errors, files created correctly. The problem is in starting from diskless client, so there is a user-id error somehow...
 
Beeblebrox said:
Code: 
rw-r-----  1 4294967294       jenkins      0 Mar  9 16:07 node.log
Click to expand...

4294967294 is the unsigned int representation of signed int -1, which in turn is the user ID of nobody. Now, please find out how nobody comes to run your script :e

Is there somehow NFS involved? In that case, you might want to check the user mapping in /etc/exports of the machine hosting the directory logs.
 
Yes, the folder housing logs is NFS exported/mounted (post #5). No restrictions other than network.
Code: 
/data/pkgjail/jenkins -network 192.168.2.0/24
 
Beeblebrox said:
Yes, the folder housing logs is NFS exported/mounted (post #5). No restrictions other than network.
Code: 
/data/pkgjail/jenkins -network 192.168.2.0/24
Click to expand...

I was wrong, 4294967294 does not translate to -1, but to -2.

From exports(5)():

In the absence of -maproot and -mapall options, remote accesses by root
will result in using a credential of -2:-2. All other users will be
mapped to their remote credential. If a -maproot option is given, remote
access by root will be mapped to that credential instead of -2:-2. If a
-mapall option is given, all users (including root) will be mapped to
that credential in place of their own.
Click to expand...
 
Sorry, I don't get what I'm supposed to change to solve this problem. Setting in /etc/exports
Code: 
maproot=jenkins*
for the log folder line seems more restrictive and excessive?

EDIT: Thanks Rolf, I did not quite get what you were trying to say but someone else explained it here.
 
You must log in or register to reply here.
Back
Top