groot_binaries create folder with wrong permissions

[AlexV]

Running
sudo groot_binaries --devel --external on a vanilla machine build this structure :

yujin@concert:~$ ll /opt/yujin/amd64/indigo-devel/
total 84
drwxr-xr-x   7 root root  4096 Jul 12 04:40 ./
drwxr-xr-x   4 root root  4096 Jul 11 05:20 ../
drwxr-xr-x   2 root root  4096 Jul 12 04:40 bin/
-rw-r--r--   1 root root     0 Jul 12 04:40 build-201607120318
-rw-r--r--   1 root root     0 Jul 12 04:40 .catkin
-rwxr-xr-x   1 root root   506 Jul 12 04:40 env.sh*
drwxr-xr-x   3 root root  4096 May 16 07:24 etc/
drwxr-xr-x 121 root root  4096 Jul 12 04:40 include/
drwx------ 120 root root 12288 Jul 12 04:40 lib/
-rw-r--r--   1 root root    69 Jul 12 04:40 .rosinstall
-rw-r--r--   1 root root   260 Jul 12 04:40 setup.bash
-rw-r--r--   1 root root  2542 Jul 12 04:40 setup.sh
-rwxr-xr-x   1 root root 12301 Jul 12 04:40 _setup_util.py*
-rw-r--r--   1 root root   270 Jul 12 04:40 setup.zsh
drwx------ 304 root root 16384 Jul 11 06:22 share/

As a result, a user other than root (yujin) cannot execute anything from lib or share (including the desktop utilities scripts)

So should we :

1. Document that groot_binaries should be run with the same user as the user who will be executing these binaries, and therefore the permissions on /opt must be changed on a vanilla machine (maybe I missed it ?)
2. Fix the script somehow, so that it create 744 permission on these directories instead of 700
3. Both ?

[Daniel Stonier]

This is curious, groot binaries actually doesn't do anything here. It's something mysterious happening somewhere in the make-cmake-catkin-jenkins-rsync pipeline. I'd like to try and find the root cause first before patching a workaround in groot binaries instead of the real problem.

[Daniel Stonier]

A result of a typical cmake-catkin install:

drwxrwxr-x  7 snorri snorri 4.0K  8월 13 11:49 ./
drwxrwxr-x  6 snorri snorri 4.0K  8월 13 11:49 ../
drwxrwxr-x  2 snorri snorri 4.0K  8월 13 11:49 bin/
-rw-rw-r--  1 snorri snorri    0  8월 13 11:49 .catkin
-rwxr-xr-x  1 snorri snorri  506  5월 30 02:17 env.sh*
drwxrwxr-x  3 snorri snorri 4.0K  8월 13 11:49 etc/
drwxrwxr-x  7 snorri snorri 4.0K  8월 13 11:49 include/
drwxrwxr-x 34 snorri snorri 4.0K  8월 13 11:49 lib/
-rw-r--r--  1 snorri snorri   71  5월 30 02:17 .rosinstall
-rw-r--r--  1 snorri snorri  260  5월 30 02:17 setup.bash
-rw-r--r--  1 snorri snorri 2.5K  5월 30 02:17 setup.sh
-rwxr-xr-x  1 snorri snorri  13K  8월 13 11:48 _setup_util.py*
-rw-r--r--  1 snorri snorri  270  5월 30 02:17 setup.zsh
drwxrwxr-x 64 snorri snorri 4.0K  8월 13 11:49 share/

So the appropriate permissions are there at that step.

[Daniel Stonier]

• CMake-Catkin Install - OK
• Jenkins /opt/yujin/amd64/indigo-devel - OK
• files.yujinrobot.com - OK
• groot_binaries --devel --external - OK
• sudo groot_binaries --devel --external - OK

So...is the problem at a higher level than this? In the ansible script that is doing the calling?

[AlexV]

I would think it comes from the machine / user setup, if the groot_binaries/rsync doesn't specify the permissions...
We need to check umask.

[AlexV]

Found that relevant piece of discussion : https://blueprints.launchpad.net/ubuntu/+spec/umask-to-0002

On my trusty at work I get :

$ cat /etc/login.defs 
[...]
ERASECHAR   0177
KILLCHAR    025
UMASK       022

And I didnt know about the pam module so I probably never changed it.

[Daniel Stonier]

My work, and home are both 022 as well. What situation (i.e. given the list
I tested above) doesn't work for you?

[Daniel Stonier]

Closing this. If you find out how this was reproduced, please reopen.