Jail question: packages with relative symlinks

[David Christensen]

On 8/25/20 2:30 PM, Valeri Galtsev wrote:
> 
> 
> On 8/25/20 4:12 PM, Valeri Galtsev wrote:
>>
>>
>> On 8/25/20 3:50 PM, David Christensen wrote:
>>> On 2020-08-25 09:51, Valeri Galtsev wrote:
>>>> Dear Experts,
>>>>
>>>> I've got question about jails, namely, what do you do if some 
>>>> package you install in jail brings relative symlink(s)?
>>>>
>>>> I install jails "by the book" and if relative symlinks are in 
>>>> /usr/local, there is no problem with those, as in jail an equivalent 
>>>> of /usr/local is
>>>>
>>>> /s/usr-local
>>>>
>>>> and the depth is the same as on real system. However, /etc in jail is
>>>>
>>>> /s/etc
>>>>
>>>> and if package brings relative symlink to /etc, in jail it will 
>>>> point nowhere. I just resolved this failure for package ca_root_nss 
>>>> in jail. This package places in
>>>>
>>>> /etc/ssl
>>>>
>>>> relative symlink:
>>>>
>>>> cert.pem --> ../../usr/local/share/certs/ca-root-nss.crt
>>>>
>>>> In jail, however it is situated in
>>>>
>>>> /s/etc/ssl
>>>>
>>>> so the above relative symlink points nowhere. I did a "trivial" 
>>>> thing, just replaced relative symlink with absolute one:
>>>>
>>>> cert.pem --> /usr/local/share/certs/ca-root-nss.crt
>>>>
>>>> ,and as this symlink is owned by the package ca_root_nss, I locked 
>>>> that package, to prevent it from "automagically" replacing symlink 
>>>> with relative if updated package is installed.
>>>>
>>>> This is kind of crude solution, standing next to the "hack", so I do 
>>>> not like what I did.
>>>>
>>>>
>>>> I wonder, how jail experts deal with relative symlinks when some 
>>>> package brings it into place where filesystem depth in jail is 
>>>> different from real system.
>>>>
>>>>
>>>> Thanks.
>>>> Valeri
>>>
>>> I am no jail expert, but AIUI jails include chroot(8) functionality. 
>>> So, all paths used within a jail will be resolved within the jailed 
>>> tree.
>>>
>>>
>>> If you log in to the jail as root and install your software from 
>>> there, it should just work.
>>>
>>
>> Having that structure with symlinks I have mentioned has a special 
>> purpose. That purpose is: the base system is mounted read only inside 
>> the jail, and only things that have to be read-write are read-write.
>>
> 
> I probably didn't explain things detailed enough.
> 
> my jail has its root in:
> 
> /jail/[jailname]
> 
> so all what is inside jail on host filesystem is visible as:
> 
> /jail/[jailname]/s/etc
> /jail/[jailname]/etc --> s/etc
> /jail/[jailname]/usr
> /jail/[jailname]/s/usr-local
> /jail/[jailname]/usr/local --> ../s/usr-local
> ...
> 
> the
> 
> /jail/[jailname]
> 
> is base system mounted read-only (with symlinks etc pointing to s/etc, 
> and others which point to a single place
> 
> /jail/[jailname]/s
> 
> which is mounted read-write, and this is the only place inside jail 
> which  is read-write. This is the wonderful idea which inside jail makes 
> base system read-only. And it is convenient, as you maintain only one 
> base system (of given version) for all jails. And as you correctly said, 
> chroot is used (in addition to other things), so inside jail what on 
> host is /jail/[jailname]/ is plainly /
> 
> I hope, this provides enough detail to un-confuse things (and the need 
> of symlinks when one sets up jails "by the book", meaning FreeBSD Handbook)
> 
> Valeri
> 
>> This basically precludes using what you suggest without diminishing 
>> robustness of jails.
>>
>> Thanks for your input though!
>>
>> Valeri

Have you tried mount_unionfs(8)?


David