UNIX for Advanced & Expert Users

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

Code:

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.

Code:

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

Code:

/ms
/data

And

Code:

cd ..

would not take me up a level.

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

Thanks

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

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.

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

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...

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