Hi,
Jeremy Fitzhardinge wrote:
>
> VSTa, of course, doesn't have the notion of chroot or any way of
> implementing it: if mount tables are just libc constructs and
> anyone can talk to a filesystem port then there's no point. Is
> there, however, some way of doing something similar?
Well to get the same effect we simply change our mount point to be partway
through a fs hierarchy. An example would be that I can make server fs/dos1
(which say has the same dir structure as a standard vsta source tree) have
an effective root of say /vsta/extern by mounting fs/dos1:vsta/extern as /
> After a little more thought, it seems like you'd do it by creating
> a new directory tree as the "chrooted" domain with an extra number
> on the end of the ownership and run the processes in there with
> the extra ID. This would prevent them from getting out so long
> as there are no other filesystems with the same or more permissive
> id. (Does this make any sense?)
Effectively yes - the only thing that strikes me as a potential problem is
the default ID offered by most fs's. For example the dos fs offers a
default read permission on all files and dirs.
Andy, any offers on how to get round this one?
Regards,
Dave
Received on Wed Mar 15 07:07:30 1995
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:17 PDT