×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On Fri, Aug 12, 2016 at 11:51 AM, Kevin Adler <kadler@xxxxxxxxxx> wrote:
Is chroot more of a *PASE* thing or an *IFS* thing?
Technically, there's a component of both (since the ILE IFS code handles
the PASE requests), but in practical terms, it only affects PASE.
So I guess navigating the IFS using WRKLNK from the CL prompt would
not be subject to chroot? How about in Qshell?
I'm trying to imagine what it would even mean (let alone what the
benefit would be) for PUB400 to set up a chroot jail for each user.
The normal way to log into PUB400 is 5250 emulator. So immediately
they are already in an environment that is outside the jail, right? Do
they put themselves into the jail if they call QP2TERM, and escape
simply by exiting their QP2TERM session?
As Holger said, most of his users probably stay within QSYS.LIB
anyway, but if they were to venture out into the rest of the IFS, it
seems as though chroot would either have no effect, or would be kind
of confusing. There may be a case for chroot on PUB400, but I don't
think it's a particularly strong one. It's a very different story on
Litmis Spaces, where you're ONLY presented the PASE environment, and
the whole experience is as Unix-like as possible and as un-IBM-i-like
as possible.
John Y.
midrange.com
