Make a subdirectory the root directory

UNIX for Advanced & Expert Users
1

I have a series of configuration files to deliver to multiple unix environments (dev, test, bench, prod etc). However I don't to modify them for each environment.

The files are text which currently contain this type of directory information

IN=/DVT/ms/sas/reception/PIL_QPA_SID/GSPIN001
OUT=/DVT/ms/sas/emission/PIL_QPA_SID/GSPIN001
TEMP=/DVT/data/PIL_QPA_SID/GSPIN001/TEMP
REJECT=/DVT/data/PIL_QPA_SID/GSPIN001/REJECT

However I want to deliver a file which contains this.

IN=/ms/sas/reception/PIL_QPA_SID/GSPIN001
OUT=/ms/sas/emission/PIL_QPA_SID/GSPIN001
TEMP=/data/PIL_QPA_SID/GSPIN001/TEMP
REJECT=/data/PIL_QPA_SID/GSPIN001/REJECT

These configuration files will be used by a 3rd party ETL tool called Datastage. Datastage requires a unix login.

Is it possible to configure a Unix user so that it believes a certain directory is the root. In this case for a user in the development environment, it would be /DVT. Thus if I login with this user and do an ll I would only see

/ms
/data

And

cd ..

would not take me up a level.

If there is an alternative which achieves this, I am open to this.

Thanks

2

Have a look at chroot man pages to see if that can do what you want...

3

chroot can do exactly that. But what do you expect the user to do in that environment? No /bin or /usr/bin so he could not run ls or any other command. ls, when used with -l, really needs to look stuff up in /etc/passwd and /etc/group but they are not around. It takes quite a bit of planning to create a chrooted environment that will work.

4

That is a very good point. In essence, the user just has to be able to run a Datastage job and be able to create and delete files within the /DVT area.

However, there are Datastage routines which shell out to Unix to run wc -l and head etc.

Must I create a subdirectory within my system to hold all of the bin commands or can I include them in the chroot definition ?

How would this be configured ?

Are there any alternatives to Chroot ?

Thanks

5

See post #3
And what perderabo is saying, that a good chroot is one a user has no doubt on what he is seeing, takes some time to figure out, because the main point is not to make a 2nd copy, but to have a restricted environment that is functional , e.g. it has all it needs to do what it is supposed to... and nothing more...
If the main purpose it trying to limit what a user can see, try a restricted shell like rksh...

6

Just on the train surfing a little.
Not sure if this c/would work...

Make a minimal install into an image, then bind loop mount the data dir inside the image.
The image containing and the loop mount might work inside the chrooted - already mounted and datafolder sharing lokal-chroot-dir.

Thus all you'd later need to handle was a 2-4gb imagefile and the real data on the comuter.
Of course, dont forget about the file permissions for the proper UIDs, host system id and image system id.

Hth