Re: More on Hard Links

[David Masover <jedi@ninja.dynup.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hubert Chan wrote:

[...]

>Really, it's a compromise.  I look at this situation and say: this is
>why we can't have cross-filesystem hardlinks.  Others may look at it
>and say: I really want cross-filesystem hardlinks, and so this is what
>I will do, which is reasonable, and doesn't completely suck.
>
>  
>

Now, the only question left is, why would someone really want 
cross-filesystem hardlinks?  With the distributed FS stuff, you don't 
need them.  (about that -- hopefully this distributed FS will function 
like RAID?)  On a single machine, the reasons I've heard for having 
separate filesystems are:

1)  speed.  We all know that it sucks to have /tmp on the same partition 
as /usr.  /tmp gets fragmented, /usr should not.  In addition, one can 
place stuff that needs faster access on a faster area of the disk, and 
generally organize things to minimize seeking.
    Solution:  All of this seems so purely mechanical that the FS should 
(eventually) be able to do it by itself.  The advantages of a single 
partition (aside from hardlinks) are that one can know nothing about the 
space requirements of a given directory, and the system will adapt itself.

2)  security.  If /bin (or any system-owned binaries) are on a partiton 
where a user has write access somewhere, that user can hardlink files 
from /bin to their own directory (say /home), so that any security patch 
applied to the original binary will overwrite it, and the user still has 
their broken copy.  If the executable has setuid, the user can now root 
the system, no matter how fanatic the admin is about updates.
    Solution:  Don't let users make hardlinks of files they wouldn't be 
allowed to create in the first place.  For example, I can't create a 
file as a normal user, make it setuid, and make it owned by root.  Short 
of this, I feel confident that at least Gentoo's package management 
software could be modified to automatically truncate every file to zero 
before it's overwritten, thus making any hardlink copies worthless.

3)  sanity.  If /tmp gets filled up, you can't create any more temporary 
files.  If /var get's filled up, for the most part, you can't log.  But 
if you manage to fill up _all_ your disk space, things get dangerous.  
Also, sometimes admins do stupid things like 'rm -rf /', and mounting / 
read-only can help.
    Solution:  Disk quotas, and a plugin that prevents you from doing 
stupid things.  For example, if I can recursively apply permissions to a 
dir, and there's a special permission that makes it impossible to remove 
a file, instead of 'mount / -o remount,ro', I'd just 'echo 1 > 
/..recursive/immutable' (or something).  Of course, now I have to go in 
and set other dirs to rewritable, but we do that in fstab anyway, and 
the nice thing here is, those settings are persistant, even without a 
config file.

4)  easier.  Maybe you have two disks.  Maybe you already have a 
partition set up a certain way.  I can't argue against this, but...
    Solution:  LVM or RAID should help here, if you really need 
hardlinks from between two otherwise physically separated dirs.  If you 
can't afford the slowdown (if any) of something like LVM, you should 
seriously consider how important cross-fs hardlinks are to you -- if 
they aren't important enough to sacrifice some speed, are they important 
enough to pay someone to code (or code yourself)?  (I don't know the 
answer to that.)


Of course, this is just how I'd like it to be.  Right now it's still 
better (at least for me) to have separate hard disks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP9aIqAisZLIF6uqOAQIX/Q//ds2BQA9XxqHA9Ntf8kQyQ6tjEfRrstVc
IZ+dBGgG/XCpizripp1+U4nW9JsLJ/TTrm2PDMC1TfLfen1P7pzgpXFP+Gxs7aTO
Y44M6LkOfAVNA1CoCLVjOaSe4Sm+dGhzZtJym74mNffvyHu163lYDEO5Qrb61HMD
um3DqH3KfXGQXZeboegbtuy1jWKYeRz+CpjLPhu/VH8iHPGNfu/9fCqP9vO3tnbr
gP82dRXM94P/MEP8pr8LmZ7OhD9gahvbO/ZgFQq2RedmpPEZKOMXHEQokWhcMCkh
bHQYK07Vc1lwuoZ4ffXnrNCrm19LGqD2qZE8NR1Yi7oLgprkOhjWZC9e2fzxywyY
QYvq6zAtQ05gmoIOYpLJiBSJzuYGfkLARCahK2BAepowbB624ic51QxGb8dbPFkl
SSDtXhf34u5wHPfGBYTdmIy8N5zmL4GAGUa/kyAqvtfZWTC7JJMGun/gPBup7FHG
WNT9a5ayZh4+9CXoJZxDXkGusARr7obI3DTDEtjyYNBfasn6drjbLzDskjKk6ZiK
yWW2VHfYpvFWMi0nuVlqwz4apmHLtvu3YyNhMV4nYsIMNQl2pf+wBlF7db7dkAu7
jNLgp46ka7PIazmQXXUkds8eYLGgKktv1UrKnTschvZyAKOrkzgwzyDN07K1UT0u
YY7VktA+0Qg=
=Z4ZJ
-----END PGP SIGNATURE-----