Closed abmusse closed 9 years ago
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
Feature implemented by Tony.
Potentially found IFS/PASE bug concerning defaulting OBJAUT in chroot.
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
BTW -- yes, likely IBM i IFS bug when chroot
Should I be submitting a formal fix request or at the guys you were chatting with going to create a PMR?
Also, I am going to change this issue to resolved.
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
Argh ... well ... looks like you will have to hit IFS with big hammer name "CHGAUT OBJAUT(*ALL)".
BTW -- yes, likely IBM i IFS bug when chroot (low use utility, well, until now).
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
See below. I omitted everything outside the path we are looking at.
$ cd /
$ ls -all
drwxrwsrwx 11 qsys 0 241664 Jun 24 17:18 QOpenSys
$ cd /QOpenSys/
$ ls -all
drwxr-xr-x 7 aaron 0 90112 Jul 22 02:16 download
$ cd download
$ ls -all
drwxr-xr-x 3 aaron 0 28672 Jul 14 23:46 ibmichroot
$ cd ibmichroot/
$ ls -all
drwxr-xr-x 3 aaron 0 8192 Jul 29 16:35 spaces
$ cd spaces/
$ ls -all
drwxr-xr-x 9 e01 0 8192 Jul 29 18:16 e01
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
After chat a few guys, what is the ls -all for the full 'outside' directory ...
#!shell
outside chroot
cd /
ls -all /
cd /QOpenSys
ls -all
... so on ...
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
What I did to test:
/QOpenSys/download/ibmichroot/spaces/e01/home
with *SECOFR
E01
, did CALL QP2TERM
to get a shell. My profile's HOMEDIR
was still set to /QOpenSys/download/ibmichroot/spaces/./e01/home/E01
so I had to cd /QOpenSys/download/ibmichroot/spaces/e01
mkdir home
and here are the results:ls -all
total 176
drwxr-xr-x 9 e01 0 8192 Jul 29 18:16 .
drwxr-xr-x 3 aaron 0 8192 Jul 29 16:35 ..
drwxr-xr-x 5 e01 0 8192 Jul 29 16:36 QOpenSys
lrwxrwxrwx 1 e01 0 34 Jul 29 16:36 bin -> /QOpenSys/usr/bin
drwxr-xr-x 3 e01 0 8192 Jul 29 16:35 dev
drwxr-xr-x 4 e01 0 8192 Jul 29 16:37 etc
drwxrwxrwx 2 e01 0 8192 Jul 29 18:16 home
lrwxrwxrwx 1 e01 0 34 Jul 29 16:36 lib -> /QOpenSys/usr/lib
lrwxrwxrwx 1 e01 0 26 Jul 29 16:36 opt -> /QOpenSys/opt
lrwxrwxrwx 1 e01 0 36 Jul 29 16:36 sbin -> /QOpenSys/usr/sbin
drwxr-xr-x 2 e01 0 8192 Jul 29 16:37 tmp
drwxr-xr-x 5 e01 0 8192 Jul 29 16:39 usr
drwxr-xr-x 3 e01 0 8192 Jul 29 16:37 var
So basically the same results as before, including the DSPAUT
settings.
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
We do not understand this issue yet, but ... This leads me to believe it has to do with defaults and how my non-chroot profile is initially creating the /home directory for user E01.
I never addressed making /home dirs with chroot_setup.sh. I was always a bit concerned about /home anything from outside chroot (wrong user profile).
What happens when you create /home from within chroot?
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
It created, but when it attempted to unlink
it couldn't because user E01
doesn't have *OBJEXIST
authority. In the end the git repository wasn't successfully created. Below I create a file in /home/E01/dir1
and attempt git status
to see it needs to be tracked, but it fails saying it isn't a git repo.
$ echo 'something' > test.txt
$ git status
fatal: Not a git repository (or any of the parent directories): .git
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
Mmm i may be little slow, but it looks like everything actually created, yes? So, are we simply concerned about the warning??
#!shell
$ git init
error: Unable to create /home/E01/dir1/.git/HEAD
warning: unable to unlink /home/E01/dir1/.git/HEAD.lock: Permission denied
$ ls -all
total 48
drwxr-xr-x 3 e01 0 8192 Jul 29 17:23 .
drwxr-xr-x 4 e01 0 8192 Jul 29 17:22 ..
drwxr-xr-x 6 e01 0 8192 Jul 29 17:23 .git
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
Let me know if you need more.
Also, when I do mkdir as profile aaron
(my profile in non-chroot) it sets the OBJAUT
to *ALL
so my profile has full authority to make changes. This leads me to believe it has to do with defaults and how my non-chroot profile is initially creating the /home
directory for user E01
.
$ pwd
/home/E01
$ mkdir dir1
$ ls -l
total 16
drwxr-xr-x 2 e01 0 8192 Jul 29 17:22 dir1
$ cd dir1
$ ls -all
total 32
drwxr-xr-x 2 e01 0 8192 Jul 29 17:22 .
drwxr-xr-x 4 e01 0 8192 Jul 29 17:22 ..
$ git init
error: Unable to create /home/E01/dir1/.git/HEAD
warning: unable to unlink /home/E01/dir1/.git/HEAD.lock: Permission denied
$ ls -all
total 48
drwxr-xr-x 3 e01 0 8192 Jul 29 17:23 .
drwxr-xr-x 4 e01 0 8192 Jul 29 17:22 ..
drwxr-xr-x 6 e01 0 8192 Jul 29 17:23 .git
$ ls -all .git/
total 136
drwxr-xr-x 6 e01 0 8192 Jul 29 17:23 .
drwxr-xr-x 3 e01 0 8192 Jul 29 17:23 ..
-rw-r--r-- 1 e01 0 23 Jul 29 17:23 HEAD.lock
drwxr-xr-x 2 e01 0 8192 Jul 29 17:23 branches
-rw-r--r-- 1 e01 0 73 Jul 29 17:23 description
drwxr-xr-x 2 e01 0 12288 Jul 29 17:23 hooks
drwxr-xr-x 2 e01 0 8192 Jul 29 17:23 info
drwxr-xr-x 4 e01 0 8192 Jul 29 17:23 refs
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
PART 2 -- integrated :system into chroot_steup.sh
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
We did not get to see the staet of /home/EO1 between steps ...
#!shell
$ pwd
/home/E01
$ ls -l
$ mkdir dir1
$ ls -l
$ cd dir1
ls -l
$ git init
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
Further laying out scenario...
Outside of chroot I ran the following to give user E01
full ownership of all files/directories in chroot:
chown -Rh E01:0 /QOpenSys/download/ibmichroot/e01
In chroot, via ssh, permissions display as follows:
$ echo $USER
e01
$ ls -all /
total 176
drwxr-xr-x 9 e01 0 8192 Jul 29 16:37 .
drwxr-xr-x 9 e01 0 8192 Jul 29 16:37 ..
drwxr-xr-x 5 e01 0 8192 Jul 29 16:36 QOpenSys
lrwxrwxrwx 1 e01 0 34 Jul 29 16:36 bin -> /QOpenSys/usr/bin
drwxr-xr-x 3 e01 0 8192 Jul 29 16:35 dev
drwxr-xr-x 4 e01 0 8192 Jul 29 16:37 etc
drwxr-xr-x 4 e01 0 8192 Jul 29 16:36 home
lrwxrwxrwx 1 e01 0 34 Jul 29 16:36 lib -> /QOpenSys/usr/lib
lrwxrwxrwx 1 e01 0 26 Jul 29 16:36 opt -> /QOpenSys/opt
lrwxrwxrwx 1 e01 0 36 Jul 29 16:36 sbin -> /QOpenSys/usr/sbin
drwxr-xr-x 2 e01 0 8192 Jul 29 16:37 tmp
drwxr-xr-x 5 e01 0 8192 Jul 29 16:39 usr
drwxr-xr-x 3 e01 0 8192 Jul 29 16:37 var
DSPAUT
of home
directory:
Display Authority
Object . . . . . . . . . . . . : /QOpenSys/download/ibmichroot/spaces/e01/home
Type . . . . . . . . . . . . . : DIR
Owner . . . . . . . . . . . . : E01
Primary group . . . . . . . . : *NONE
Authorization list . . . . . . : *NONE
Data --Object Authorities--
User Authority Exist Mgt Alter Ref
*PUBLIC *RX
E01 *RWX
Now to attempt git init
and produce permission error:
$ pwd
/home/E01
$ mkdir dir1
$ cd dir1
$ git init
error: Unable to create /home/E01/dir1/.git/HEAD
warning: unable to unlink /home/E01/dir1/.git/HEAD.lock: Permission denied
If I mkdir dir1
, then CHGAUT
of dir1
to be OBJAUT(*ALL)
, and then git init
it works just fine.
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
Part 1 ... you did not post the actual error ... so guessing ... maybe permissions on actual SC1 inside chroot is to "tight".
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
Part 2 ... however may be useful to include a :system directive to chroot_setup.sh.
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
well ... appears you have understanding of chmod, but for review ...
#!shell
chmod 750 dir-or-file
7 - owner (chown profile)
5 - group (group profile)
0 - public (*PUBLIC profile)
-- values --
4 - 'read'
2 - 'write'
1 - 'execute'
0 - 'no permission'
Speaking generally, you should be able to setup git without resorting to anything OBJAUT(*ALL).
Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
general IFS related issues for PASE are best handled from PASE (chmod, chown).
I started typing out a long response but then realized it might be better to make sure I am using the chmod
and chown
commands correctly. After using chroot_minimal.lst
to create the chroot I issue the following:
env_path=/QOpenSys/download/ibmichroot/spaces/e01
chown -Rh E01:0 $env_path
chmod 700 $env_path/home/E01/.ssh
chmod 600 $env_path/home/E01/.ssh/id_rsa
chmod 644 $env_path/home/E01/.ssh/id_rsa.pub
touch $env_path/home/E01/.ssh/authorized_keys
chmod 644 $env_path/home/E01/.ssh/authorized_keys
I believe the chmod
for .ssh
is inconsequential concerning the git init
permission issue. Does this look correct? If not, what else do I need to add/change?
Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).
Mmm ... OBJAUT(*ALL), nothing PASE ... but ... general IFS related issues for PASE are best handled from PASE (chmod, chown).
I would think are failing our chroot experience if we have to fall back to system for benign application like git.
Original report by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).
I ran into an issue with git in chroot where I was getting permission denied for things even when user owned all directories and chmod was set to 777.
The fix was to run and have
OBJAUT(*ALL)
.Is there a way to do equivalent of
OBJAUT(*ALL)
with a PASE command other thansystem
? Maybe we need to add a:system
section to the.lst
files? Thoughts?