Hi Holger,Correct, but when AFD wants to distribute the file via for example FTP
On Thu, Oct 25, 2012 at 12:13:40PM +0000, Holger Kiehl wrote:as of linux 3.6 hardlink restrictions to the Linux VFS have been enabled
by default. This breaks the application AFD [1] of which I am the author.
Sorry this created a problem for you!
Internally it uses hardlink to distribute files. The reason for hardlinks
is that AFD can distribute one file to many destinations and for each
distributing process it creates a directory with hardlinks to the original
file. That way AFD itself never needs to copy the content of a file. Another
nice feature about hardlinks was that there is no need to have any logic in
the code needing AFD to know where the original file was, each distributing
process could delete its hardlink and the last one would delete the real
file. This way AFD could distribute files at rates of more then 20000 files
per second (in benchmarks). This has worked from the first linux kernel
up to 3.5.7 and with solaris, hpux, aix, ftx, irix. As of 3.6 this does
not work for files where AFD does not have write permissions. It was always
sufficient to just have read permission on a file it wants to distribute.
Just to clarify, not even read access was needed for hardlinks:
$ whoami
kees
$ ls -l /etc/shadow
-r--r----- 1 root shadow 3112 Oct 22 17:02 /etc/shadow
$ ln /etc/shadow /tmp/ohai
$ ls -l /tmp/ohai
-r--r----- 2 root shadow 3112 Oct 22 17:02 ohai
You mention "the last one would delete the real file". That would haveRight, it must have write permission on the directory that is monitored
required AFD to have write permission to the directory where the original
file existed? Maybe there is something in your architecture that could
take advantage of that? Directory group-write set-gid? I haven't taken
a look at AFD's code.
This is exactly what AFD tries to avoid. AFD is used on systems where itThe fix for the "at" daemon [2] mentioned in the commitdiff [3] cannot
be used for AFD since it is not run with root privileges. Is there any
other way I can "fix" my application? I currently can see no other way
then doing it via: echo 0 > /proc/sys/fs/protected_hardlinks
You said you have read access to these files, so perhaps you can make
a copy when you have read but not write, and then all the subsequent
duplication would be able to hardlink?
If you wanted to turn off the sysctl, you could have AFD could shipYes, that could be done. However, I do not want as a maintainer of one
files in /etc/sysctl.d/ (or your distro equivalent) to turn it off.
I'm sure there are plenty of options available.Sorry, I cannot see them. But please if you or others have more ideas
Ubuntu is known to be very user friendly and mostly used by users on theirWhy is such a fundamentally change to the linux kernel activated by default?
Based on about two years of testing in Ubuntu, the number of problems
was vanishingly small, so the security benefit is seen to outweigh
the downside.
So you too would say not all distributions would enable it by default.Would it not be better if it is the other way around, that the system
administrator or distributions enable this?
Virtually all distributions would have turned this on by default,
so it seemed better to many people to just make it the default in the
kernel. Only unusual corner-cases would need it disabled.