Why not just not support hard links?
Why not just not support hard links?
Posted Sep 2, 2004 9:40 UTC (Thu) by rjw (guest, #10415)In reply to: Why not just not support hard links? by walles
Parent article: More notes on reiser4
Mainly useful for things like chrooting nowadays AFAIK.
Posted Sep 2, 2004 10:03 UTC (Thu)
by walles (guest, #954)
[Link] (5 responses)
Posted Sep 2, 2004 11:26 UTC (Thu)
by hensema (guest, #980)
[Link] (4 responses)
However, with hard links, you only need one instance of a file on disk, which saves space.
Note that hard linking from inside a chroot to main system files (such as /bin/bash) is not a very smart thing to do, as chrooted users can then modify exactly the files you wanted to prevent them from modifying. So you always need two copies of a file.
Posted Sep 2, 2004 12:04 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link]
Posted Sep 2, 2004 12:52 UTC (Thu)
by maniax (subscriber, #4509)
[Link] (1 responses)
Posted Sep 2, 2004 16:35 UTC (Thu)
by Ross (guest, #4065)
[Link]
Posted Sep 2, 2004 19:52 UTC (Thu)
by oak (guest, #2786)
[Link]
Please forgive my ignorance, but what do hard links have to do with chrooting? How exactly are hard links used together with chroot jails?Why not just not support hard links?
You cannot symlink to files outsides a chroot. So, if you want to create a chroot jail without hard links, then you'd have to copy all files you need inside the chroot, effectively duplicating those files.Why not just not support hard links?
So, in other words, security concerns make the space-saving of hardlinks in a chroot environment useless, since duplication is necessary anyway.Why not just not support hard links?
Using hardlinks for chroot jails is a bad idea. Firstly, you don't have a good way to protect the file, and if you do some modifications on the chroot environment's structure, you'll have to update all it's users (or, if the tool that update software in it uses unlink() and then open(), you'll have to update the users of the env. on every update).Why not just not support hard links?
Just use bind mounts, which will save more space, and make it possible to have the evironment mounted somewhere read-write for updates, and somewhere read-only, for use.
If the file is not writeable, there is no problem. If the process runningWhy not just not support hard links?
in the jail is under uid 0, then you aren't gaining anything by the jail
anyway.
Good point would be that it's easier to get security updated versions of Why not just not support hard links?
the libraries etc inside the chroots. Same can of course achieved easier
with mount --bind's from chroot "template" directory, but with hardlinks
you can pick and choose what you put input chroots from the template
directory structure.