Prerequisites for chdir at Init() time.

[Joel Sherrill]

On Wed, Aug 21, 2019 at 2:34 PM Jonathan Brandmeyer
<jbrandmeyer at planetiq.com> wrote:
>
> Are there any special pre-requsites to using the chdir system call
> effectively in RTEMS?
>
> I've got a function which unpacks a tarred up filesystem by chdir into
> a chosen directory, unpacking the filesystem, and then chdir() back to
> "/".  If I call this function from the RTEMS shell, everything behaves
> normally, and the files appear relative to the path I cd'ed into.
> However, if I call it directly from Init(), it acts strangely.  The
> chdir() call reports success, and subsequent call to getcwd() returns
> the directory that I chdir'ed into.  However, the tarball gets
> unpacked relative to the filesystem root.

My first suspicion was that the tar file paths actually start with /.
But further investigation caused me to doubt that.

>
> chdir("/mnt/somepath") appears to succeed.  A subsequent call to
> getcwd() also returns the directory cd'ed into.
>
> However, the subsequent unpacking of the tarball does so into the root.
>
> I did some digging into the shell initialization code, and saw that
> `rtems_shell_init_user_env()` is constructing a private user
> environment for the shell thread.  In the process of doing so, it
> makes a suspicious system call: chroot("/").

This would be done to ensure that if the calling thread had done a chroot
to another directory that it didn't get inherited.


> Sure enough, adding chroot("/") early enough in my POSIX_Init() allows
> subsequent chdir operations to have the right side-effects on creat()
> and open() calls.
>
> What's up with that?  Is it intentional?  Or is the shell's chroot()
> covering up some deficiency in the way that the
> `rtems_global_user_env` is getting initialized when the IMFS rootfs is
> set up?

I would tend to agree. It is defaulted to a null filesystem in __userenv.c.

That would make sense when there is no filesystem or a filesystem like
the device only one.

I think that mounting a root file system which supports some minimum
core capabilities needs to implicitly do a chroot("/") to override this.
The IMFS is the only file system at the current time that can do that.

Finding the right place and logic to do this will be the trick.

Without involving the shell, do you have a simple test case for this?

--joel


> Thanks,
> --
> Jonathan Brandmeyer
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users