1

I'm facing a strange file access issue.

Linux system is RedHat 5.5

On this machine, when I log in as the given user: deploy_user, I can see that I have valid access to /path/to/the/folder/subfolder/file.txt

ls -l /path/to/the/folder shows (this means upto this path I can see contents):

13:50:53 drwxr-x--- 2 root dbgroup    4096 Apr 27 14:38 subfolder

and in folder subfolder, file.txt has the following access (ls -l output)

13:50:53 -rwxr----- 1 root dbgroup  1620 Dec  9 15:28 file.txt

On the server at $ prompt, if I do: id deploy_user I see I'm (being deploy_user) in dbgroup (i.e. anyone in dbgroup group can change directory to subfolder) and can read the file file.txt.

When I'm running the same commands in a free-style Jenkins job and running the job on this linux machine as a node/slave (where Jenkins connects only to this node/slave as user deploy_user using it's SSH keys successfully), I can't cd (change directory) and list or ls and read or cat this file.

NOTE: I'm restricting the jenkins job to run on a particular slave (using a label) i.e. it'll run the job only on a given machine (as I mentioned above).

In the jenkins job, all I'm running are the following commands:

echo "I'm `whoami`"
echo "I'm in: $(id `whoami`)"
echo
groups
echo
echo "Again, my groups for: $(groups `whoami`)"
echo
cat /etc/group | grep "^dbgroup"
echo
echo
cd /path/to/the/folder
pwd && echo "It works! upto /path/to/the/folder path in Jenkins job."
echo
echo
cd /path/to/the/folder/subfolder || echo "cd to subfolder - didnt work"
echo
ls -l /path/to/the/folder/subfolder/file.txt || echo "ls on file.txt - didn't work"
echo
echo "Sleeping for 60 seconds ..." && sleep 60

Main output from Jenkins job is:

13:50:53 I'm - deploy_user
13:50:53 I'm in: uid=3000(deploy_user) gid=3000(deploy_user) groups=4000(deployer),6001(dba),6081(osinstall),10121(dbgroup)
13:50:53
13:50:53 deployer dba osinstall
13:50:53
13:50:53 Again, my groups for: deploy_user : deployer dba osinstall dbgroup
13:50:53
13:50:53 dbgroup:x:10121:user1,user2,appuser3,svcuser4,deploy_user
13:50:53
13:50:53
13:50:53 /path/to/the/folder
13:50:53 It works! upto /path/to/the/folder path in Jenkins job.
13:50:53
13:50:53
13:50:53 /tmp/hudson58581.sh: line 7: cd: /path/to/the/folder/subfolder: Permission denied
13:50:53: cd to subfolder - didnt work
13:50:53
13:50:53 ls: /path/to/the/folder/subfolder/file.txt: Permission denied
13:50:53 ls on file.txt - didn't work
13:50:53
13:50:53 Sleeping for 60 seconds ...

Any idea why output of groups and groups deploy_user are different. groups command by defaults works for the current logged in user (which is whoami and it shows I'm deploy_user).

I also checked the groupID in the ls -l output for both subfolder/file.txt and it's 10121

Thanks.

AKS
  • 16,482
  • 43
  • 166
  • 258
  • Are your systems by any chance using some other authentication method besides local files (like NIS+/Active Directory/etc)? Are they matched in terms of the authentication method? Are they both mounting the folder from in the same location and from the same source? – Dan Cornilescu May 26 '15 at 19:10
  • yes mounts and all are same. – AKS May 26 '15 at 21:03

2 Answers2

1

OK, the issue was someone added dbgroup user recently but it got added after the node was created/configured/started i.e. for node to read the new settings, it had to be restarted.

That's why on the machine itself, everything was working fine at $ prompt but in Jenkins job, it was failing.

After I restarted the node (which was running the job aka was restricting the job to run only on a given slave with a label), the permission denied error went away.

Now, both commands groups and groups `whoami` shows the same # of groups.

AKS
  • 16,482
  • 43
  • 166
  • 258
0

Jenkins typically builds across multiple machines, with a master and a slave.

Check to see that the groupIds for both the machines have the same "id number". If it doesn't, then you might be confusing "dbgroup" on the master node with "dbgroup" on the slave, which is an entirely different group. Linux only really uses the number.

You might also test again with the "print groupID" option, instead of the default of "print group name". ls -ln

Also, keep in mind that the Jenkins job (launched in /tmp/hudson58581.sh may be running as a different user). The pre-build scripts, build scripts, and post-build scripts all get their own shells, which means little that can be gleaned from one can be known to apply to the others.

Also, Jenkins handles its "on the master" slave quite differently than remote masters. If you are building on the master's slave, I recommend you migrate to a remote slave right away. It's because remote slaves scale, and it is not worth accumulating logic that won't.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • I forgot to add this. When Jenkins is running the jobs on the slave server and when I do ps -eAf|grep deploy_user I see that everything is running as deploy_user userid whatever jenkins runs in the job including the slave.jar (java process). – AKS May 26 '15 at 20:39
  • With ls -ln, I see the same groupID for the subfolder/file.txt what I see for the group dbgroup (10121). – AKS May 26 '15 at 20:43
  • I also forgot to mention that I'm restricting the job to run only on a given machine so that Jenkins can't run it on master or any X slave. It'll only run on a slave which has the specific label on it. – AKS May 26 '15 at 21:04