12

Although there is another question with similar topic, it does not cover the memory use by the shared libraries in chrooted jails.

Let's say we have a few similar chroots. To be more specific, exactly the same sets of binary files and shared libraries which are actually hard links to the master copies to conserve the disk space (to prevent the potential possibility of a files alteration the file system is mounted read only).

How is the memory use affected in such a setup?

Community
  • 1
  • 1
Serge
  • 6,088
  • 17
  • 27

3 Answers3

8

As described in the chroot system call:

This call changes an ingredient in the pathname resolution process and does nothing else.

So, the shared library will be loaded in the same way as if it were outside the chroot jail (share read only pages, duplicate data, etc.)

http://man7.org/linux/man-pages/man2/chroot.2.html

hdante
  • 7,685
  • 3
  • 31
  • 36
  • Indeed. We look and we don't see :). I wish to give the bounty to every one who answered, but then I need to make special arrangement for this and most likely it is against the rules. Your answer is the most exact one. Thanks. – Serge Dec 28 '13 at 01:10
3

Because hardlinks share the same underlying inode, the kernel treats them as the same item when it comes to caching/mapping.

You'll see filesystem cache savings by using hardlinks, as well as disk-space savings.

The biggest issue I'd have with this is that if someone manages so subvert the read-only nature of one of the chroot environments, then they could subvert all of them by making modifications to any of the hardlinked files.

Anya Shenanigans
  • 91,618
  • 3
  • 107
  • 122
  • If someone manages to alter read-only mounted fs that means that (s)he managed to elevate his privileges to the root level (provided it was not done by any "backdoors" I could leave unintentionally). That means that the whole system is compromised, so nothing to discuss in this case. So, do you think that the shared library will be mapped once and physical pages will be actually shared by the chrooted processes? – Serge Dec 27 '13 at 22:53
  • The code pages are shared amongst the chrooted processes because the underlying file is the same one across all of them. – Anya Shenanigans Dec 27 '13 at 23:57
  • The simplest analogy I can come up with to explain hardlinks vs files is that hardlinks are the keys to the apartment - each one gets you into the same apartment, while the underlying file is the apartment itself. Each key doesn't give you a new apartment, it merely allows another access to the same apartment. – Anya Shenanigans Dec 28 '13 at 00:13
2

When I set this up, I copied the shared libraries per chroot instead of linking to a read-only mount. With separate files, the text segments were not shared. It's likely that the same inode will map to the same read-only text segment, but this may vary with available memory management hardware and similar architectural details.

Try this experiment on your system: write a small program that makes some minimal use of a large shared library. Run twenty or thirty chroot jails as you describe, each with a running copy of the program. Check overall memory usage before & during running, and dissect one instance to get a good text/data segment breakdown. If memory use increases by the full size of the map for each instance, the segments are not shared. Conversely, if memory use goes up by a fraction of the map, the segments are shared.

mpez0
  • 2,815
  • 17
  • 12
  • Let's assume the architecture is most commonly used, i.e. x86, so the MMU is capable to manage virtual address space using reasonable page sizes and is able to map a single physical memory page into several virtual address spaces. As for experiment - I understand how to get the estimation, however it requires me to dig into the sources anyway in order to get how a shared lib affects the RSS size reported by the system. I offered the bounty to get an answer, not a way how to get one ;) – Serge Dec 27 '13 at 23:01