Re: chroot, Doctrine, ZendFrameWork

Aaron

This fits what I now think I grasp about this.

My question about IASPs still holds - within and IASP there IS a QSYS.LIB since some release back in the V5 area. In a regular IBM i job that has activated the IASP, the library list is a combination of *SYSBAS and the QSYS.LIB of the IASP - seamlessly done by the system.

Now let's say that you have an IASP named IASPVERN - there will be a directory off the root names IASPVERN, and in that directory will be a QSYS.LIB. This directory can have most object types that the system has.

If you chroot to /IASPVERN, , the objects in its /IASPVERN/QSYS.LIB would seem to be accessible, since they are within the jail, right? Now you'd need to use their IFS path name for some things.

I know I'm talking probably over my head - but the article by Tony does speak of IASPs helping to solve some of the issues with library-object kinds of things, as I recall.

Do you have an IASP to try this on, Aaron? Or anyone?

BTW, IASPs are not just for HA - they can be used as I'm describing to install test and production versions of applications. The concept seems to fit what y'all are saying about chroot.

Regards
Vern

On 10/27/2015 2:56 PM, Aaron Bartell wrote:

When you ssh into an IBM i environment you can be placed into a chroot
environment by default depending on how the HOMEDIR is set on a user
profile. For example,
HOMEDIR('/QOpenSys/litmis/spaces/ULKUMH/./home/usrlnmki') will run the
chroot command where the period is specified. So when this particular user
logs in they will be placed in directory
/QOpenSys/litmis/spaces/ULKUMH/home/usrlnmki. If they do a "ls /" they
will see whatever is in directory /QOpenSys/litmis/spaces/ULKUMH. They
will not be able to "cd .." up past /QOpenSys/litmis/spaces/ULKUMH.

Here an example of me SSH'ing into a chroot environment and listing the
root. Note the absence of /QSYS.LIB. Note, though, that I can still
connect to the local database with SQL CLI APIs (per the language database
adapters).

$ ls -all /
total 176
drwxrwsrwx 9 usrlnmki 0 8192 Oct 27 18:15 .
drwxrwsrwx 9 usrlnmki 0 8192 Oct 27 18:15 ..
drwxrwsrwx 5 usrlnmki 0 8192 Sep 10 21:54 QOpenSys
lrwxrwxrwx 1 usrlnmki 0 34 Sep 10 21:49 bin ->
/QOpenSys/usr/bin
drwxrwsrwx 3 usrlnmki 0 8192 Sep 10 21:46 dev
drwxr-xr-x 5 usrlnmki 0 8192 Sep 10 21:52 etc
drwxr-s--- 3 usrlnmki 0 8192 Sep 10 21:46 home
lrwxrwxrwx 1 usrlnmki 0 34 Sep 10 21:49 lib ->
/QOpenSys/usr/lib
lrwxrwxrwx 1 usrlnmki 0 26 Sep 10 21:49 opt ->
/QOpenSys/opt
lrwxrwxrwx 1 usrlnmki 0 36 Sep 10 21:49 sbin ->
/QOpenSys/usr/sbin
drwxrwsrwt 5 usrlnmki 0 8192 Oct 21 00:44 tmp
drwxrwsrwx 4 usrlnmki 0 8192 Sep 10 21:52 usr
drwxrwsrwx 3 usrlnmki 0 8192 Sep 10 21:52 var


Aaron Bartell
litmis.com - Services for open source on IBM i


On Tue, Oct 27, 2015 at 2:40 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Thanks for the replies, Jim and Aaron.

Regarding connections to IBM i databases, I'm already familiar with SQL CLI
DB and toolkit interfaces which accompany *nix language environments (PHP,
Ruby, Python, Node.js, etc.).

My question about accessing /qsys.lib was a curiosity about "visibility"
and "access" from *nix shells, via *SHHD.

While at the command line, what happens if users enter:

cd /

ls

Would /qsys.lib appear in the directory structure?

I gather from Aaron's response - that it would depend on the authority of
the "user" of the IBM i JOB which accompanies a *SSHD connection.



On Tue, Oct 27, 2015 at 1:20 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

As a follow-up to Vern's question regarding access to /qsys.lib;

Without a

chroot setup, would users of the *SSHD daemon be able to access

/qsys.lib/*

objects otherwise, from remote *nix shells?

When a user logs into the *SSHD daemon from LUW** they are literally on

the

IBM i with a dedicated IBM i job; complete with a library list and all.
Similar in nature to a telnet session where 5250 is your "shell".

**LUW=Linux/Unix/Windows


Aaron Bartell
litmis.com - Services for open source on IBM i
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.