Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Is it as simple as something like this patch below (minus the printk)?
Not likely, but then I'm not a filesystem guru.
???
--- old/fs/namei.c 2007-12-15 12:33:13.000000000 -0500
+++ linux/fs/namei.c 2007-12-18 17:37:04.000000000 -0500
@@ -2398,8 +2398,11 @@
if (error)
goto out;
error = -EXDEV;
- if (old_nd.mnt != nd.mnt)
- goto out_release;
+ if (old_nd.mnt != nd.mnt) {
+ if (old_nd.mnt->mnt_sb != nd.mnt->mnt_sb)
+ goto out_release;
+ printk("sys_linkat: old_nd.mnt != nd.mnt, but sb is the same. Continuing..\n");
+ }
new_dentry = lookup_create(&nd, 0);
error = PTR_ERR(new_dentry);
if (IS_ERR(new_dentry))
Mark Lord wrote:
> Why does link(2) not support hard-linking across bind mount points
> of the same underlying filesystem ?
>
> Is it as simple as something like this patch below (minus the printk)?
> Not likely, but then I'm not a filesystem guru.
>
> ???
>
> --- old/fs/namei.c 2007-12-15 12:33:13.000000000 -0500
> +++ linux/fs/namei.c 2007-12-18 17:37:04.000000000 -0500
> @@ -2398,8 +2398,11 @@
> if (error)
> goto out;
> error = -EXDEV;
> - if (old_nd.mnt != nd.mnt)
> - goto out_release;
> + if (old_nd.mnt != nd.mnt) {
> + if (old_nd.mnt->mnt_sb != nd.mnt->mnt_sb)
> + goto out_release;
> + printk("sys_linkat: old_nd.mnt != nd.mnt, but sb is the same.
> Continuing..\n");
> + }
> new_dentry = lookup_create(&nd, 0);
> error = PTR_ERR(new_dentry);
> if (IS_ERR(new_dentry))
..
The patch seems to work for me after some light testing on ext3 here.
But I have no idea about other filesystems, or if there's some kind of
race condition or something. Or maybe we just never bothered ?
Cheers
On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
> Why does link(2) not support hard-linking across bind mount points
> of the same underlying filesystem ?
Because it gives you a security boundary around a subtree.
On Tue, Dec 18, 2007 at 11:00:16PM +0000, Al Viro wrote:
> On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
> > Why does link(2) not support hard-linking across bind mount points
> > of the same underlying filesystem ?
>
> Because it gives you a security boundary around a subtree.
PS: that had been discussed quite a few times, but to avoid searches:
consider e.g. mount --bind /tmp /tmp; now you've got a situation when
users can't create links to elsewhere no root fs, even though they
have /tmp writable to them. Similar technics works for other isolation
needs - basically, you can confine rename/link to given subtree. IOW,
it's a deliberate feature. Note that you can bind a bunch of trees
into chroot and get predictable restrictions regardless of how the
stuff might get rearranged a year later in the main tree, etc.
Al Viro wrote:
> On Tue, Dec 18, 2007 at 11:00:16PM +0000, Al Viro wrote:
>> On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
>>> Why does link(2) not support hard-linking across bind mount points
>>> of the same underlying filesystem ?
>> Because it gives you a security boundary around a subtree.
>
> PS: that had been discussed quite a few times, but to avoid searches:
> consider e.g. mount --bind /tmp /tmp; now you've got a situation when
> users can't create links to elsewhere no root fs, even though they
> have /tmp writable to them. Similar technics works for other isolation
> needs - basically, you can confine rename/link to given subtree. IOW,
> it's a deliberate feature. Note that you can bind a bunch of trees
> into chroot and get predictable restrictions regardless of how the
> stuff might get rearranged a year later in the main tree, etc.
..
Thanks, Al. That makes sense for a multi-user system, so I'm happy.
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
The patch is simple enough when needed, though.
Cheers
--- old/fs/namei.c 2007-12-15 12:33:13.000000000 -0500
+++ linux/fs/namei.c 2007-12-18 22:41:19.000000000 -0500
@@ -2398,7 +2398,7 @@
if (error)
goto out;
error = -EXDEV;
- if (old_nd.mnt != nd.mnt)
+ if (old_nd.mnt->mnt_sb != nd.mnt->mnt_sb)
goto out_release;
new_dentry = lookup_create(&nd, 0);
error = PTR_ERR(new_dentry);
Mark Lord wrote:
> But.. pity there's no mount flag override for smaller systems,
> where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying
filesystem. If you need to make it on the bound mount, that is, if you
can't locate the underlying filesystem to make the hard link, you can
use a symbolic link.
Al Viro <[email protected]> wrote:
> On Tue, Dec 18, 2007 at 11:00:16PM +0000, Al Viro wrote:
>> On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
>> > Why does link(2) not support hard-linking across bind mount points
>> > of the same underlying filesystem ?
>>
>> Because it gives you a security boundary around a subtree.
>
> PS: that had been discussed quite a few times, but to avoid searches:
> consider e.g. mount --bind /tmp /tmp; now you've got a situation when
> users can't create links to elsewhere no root fs, even though they
> have /tmp writable to them. Similar technics works for other isolation
> needs - basically, you can confine rename/link to given subtree. IOW,
> it's a deliberate feature. Note that you can bind a bunch of trees
> into chroot and get predictable restrictions regardless of how the
> stuff might get rearranged a year later in the main tree, etc.
Since nobody knows about this "security boundary" and everybody knows about
the annoying "can't link across bind-mountpoints bug", what about introducing
a mount option to allow link()ing?
On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote:
> Since nobody knows about this "security boundary" and everybody knows about
> the annoying "can't link across bind-mountpoints bug",
... how about teaching people to RTFM? Starting, perhaps, with man 2 link?
Hi Al,
Al Viro <[email protected]> writes:
> On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote:
>
>> Since nobody knows about this "security boundary" and everybody knows about
>> the annoying "can't link across bind-mountpoints bug",
>
> ... how about teaching people to RTFM? Starting, perhaps, with man 2
> link?
Making people RTFM? Are you trippin? ;)
But in the sense of providing mechanism not (only) policy, a mount
option for that behaviour would still be nice.
Hannes
Al Viro wrote:
> On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote:
>
>> Since nobody knows about this "security boundary" and everybody knows about
>> the annoying "can't link across bind-mountpoints bug",
>
> ... how about teaching people to RTFM? Starting, perhaps, with man 2 link?
..
Mmm.. that's a programmers' man page, not a user/admin page.
Something in mv(1) would be very useful to have.
And perhaps a mount flag to select desired behaviour,
since virtually everyone expects it to "just work" that way,
and it doesn't.
I'll happily generate a patch if we can agree on the correctness
of the sample patch I posted earlier, plus a suitable mount flag name.
Cheers
David Newall wrote:
> Mark Lord wrote:
>> But.. pity there's no mount flag override for smaller systems,
>> where bind mounts might be more useful with link(2) actually working.
>
> I don't see it. You always can make hard link on the underlying
> filesystem. If you need to make it on the bound mount, that is, if you
> can't locate the underlying filesystem to make the hard link, you can
> use a symbolic link.
..
Where people run into trouble with this, is when they simply go to
move a huge file (DVD image) from one directory to another,
where the target happens to be on a different bind point of the
same underlying filesystem.
This can happen in a variety of common ways, including accessing
over CIFS or Samba.
And the result is a very very long delay while we copy 4-8GB of data
instead of simply moving the link.
Cheers
Mark Lord wrote:
> David Newall wrote:
>> Mark Lord wrote:
>>> But.. pity there's no mount flag override for smaller systems,
>>> where bind mounts might be more useful with link(2) actually working.
>>
>> I don't see it. You always can make hard link on the underlying
>> filesystem. If you need to make it on the bound mount, that is, if
>> you can't locate the underlying filesystem to make the hard link, you
>> can use a symbolic link.
> ..
>
> Where people run into trouble with this, is when they simply go to
> move a huge file (DVD image) from one directory to another,
> where the target happens to be on a different bind point of the
> same underlying filesystem.
Does that prevent you from seeing the underlying filesystem?
> Why does link(2) not support hard-linking across bind mount points
> of the same underlying filesystem ?
Whenever we get mount -r --bind working properly (which I use to place
copies of necessary shared libraries inside chroot jails while allowing
page cache sharing), this feature would break security.
mkdir /usr/lib/libs.jail
for i in $LIST_OF_LIBRARIES; do
ln /usr/lib/$i /usr/lib/libs.jail/$i
done
mount -r /usr/lib/libs.jail /jail/lib
chown prisoner /usr/log/jail
mount /usr/log/jail /jail/usr/log
chrootuid /jail prisoner /bin/untrusted &
Although protections should be enough, but I'd rather avoid having the
prisoner link /jail/lib/libfoo.so (write returns EROFS) to /jail/usr/log
where it's potentially writeable.
[email protected] wrote:
>> Why does link(2) not support hard-linking across bind mount points
>> of the same underlying filesystem ?
>
> Whenever we get mount -r --bind working properly (which I use to place
> copies of necessary shared libraries inside chroot jails while allowing
> page cache sharing), this feature would break security.
..
No, that would still function exactly as it does today.
The alternate behaviour that is desired for non-chroot purposes
would be per-bind-mount, and would require a mount flag to activate.
Cheers
On Wed, 19 Dec 2007, Al Viro wrote:
> On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote:
> > Since nobody knows about this "security boundary" and everybody knows about
> > the annoying "can't link across bind-mountpoints bug",
>
> ... how about teaching people to RTFM? Starting, perhaps, with man 2 link?
What about reading POSIX which says
1264 [EXDEV]
1265 Improper link. A link to a file on another file system was attempted.
So if the link creates a file on NOT another filesystem (which is the point
of bind mounts), it should NOT return EXDEV.
Having an artificial boundary between different views to a fs may happen to
be a security feature if used with care, but most users do expect the
opposite and wonder why mv is needlessly slow. I'm not even sure if
defaulting to having a barrier is sane at all, but if people confuse
filesystems and mountpoints^W^W^W^Wuse this feature, they will depend on
this feature not changing:-)
--
"It is generally inadvisable to eject directly over the area you just
bombed."
-U.S. Air Force Manual
Mark Lord wrote:
> Why does link(2) not support hard-linking across bind mount points
> of the same underlying filesystem ?
do we need link(2) at all? bind mounts are supposed to be (hard/soft)
link minus the headaches.
--
Democracy is about two wolves and a sheep deciding what to eat for dinner.
On Wed, 19 Dec 2007, David Newall wrote:
> Mark Lord wrote:
> > But.. pity there's no mount flag override for smaller systems,
> > where bind mounts might be more useful with link(2) actually working.
>
> I don't see it. You always can make hard link on the underlying filesystem.
> If you need to make it on the bound mount, that is, if you can't locate the
> underlying filesystem to make the hard link, you can use a symbolic link.
i run into it on a system where /home is a bind mount of /var/home ... i
did this because:
- i prefer /home to be nosuid,nodev (multi-user system)
- i prefer /home to not be on same fs as /
- the system has only one raid1 array, and i can't stand having two
writable filesystems competing on the same set of spindles (i like to
imagine that one fs competing for the spindles can potentially result
in better seek patterns)
- i didn't want to do /var -> /home/var or vice versa ... because i don't
like seeing "/var/home/dean" when i'm in my home dir and such.
- i didn't want to try to balance disk space between /var and /home
- i didn't want to use a volume mgr just to handle disk space balance...
so i gave a bind mount a try.
i was surprised to see that mv(1) between /var and /home causes the file
to be copied due to the link(1) failing...
it does seem like something which should be configurable per mount
point... maybe that can be done with the patches i've seen going around
supporting per-bind mount read-only/etc options?
-dean
p.s. in retrospect i probably could have arranged it more like this:
mount /dev/md1 $tmpmntpoint
mount --bind $tmpmntpoint/var /var
mount --bind $tmpmntpoint/home /home
umount $tmpmntpoint
except i can't easily specify that in fstab... and neither of the bind
mounts would show up in df(1). seems like it wouldn't be hard to support
this type of subtree mount though. mount(8) could support a single
subtree mount using this technique but the second subtree mount attempt
would fail because you can't temporarily remount the device because the
mount point is gone.
On Dec 28 2007 18:53, dean gaudet wrote:
>p.s. in retrospect i probably could have arranged it more like this:
>
> mount /dev/md1 $tmpmntpoint
> mount --bind $tmpmntpoint/var /var
> mount --bind $tmpmntpoint/home /home
> umount $tmpmntpoint
>
>except i can't easily specify that in fstab... and neither of the bind
>mounts would show up in df(1). seems like it wouldn't be hard to support
>this type of subtree mount though. mount(8) could support a single
>subtree mount using this technique but the second subtree mount attempt
>would fail because you can't temporarily remount the device because the
>mount point is gone.
Why is it gone?
mount /dev/md1 /tmpmnt
mount --bind /tmpmnt/var /var
mount --bind /tmpmnt/home /home
Is perfectly fine, and /tmpmnt is still alive and mounted. Additionally,
you can
umount /tmpmnt
now, which leaves only /var and /home.
On Sat, 29 Dec 2007, Jan Engelhardt wrote:
>
> On Dec 28 2007 18:53, dean gaudet wrote:
> >p.s. in retrospect i probably could have arranged it more like this:
> >
> > mount /dev/md1 $tmpmntpoint
> > mount --bind $tmpmntpoint/var /var
> > mount --bind $tmpmntpoint/home /home
> > umount $tmpmntpoint
> >
> >except i can't easily specify that in fstab... and neither of the bind
> >mounts would show up in df(1). seems like it wouldn't be hard to support
> >this type of subtree mount though. mount(8) could support a single
> >subtree mount using this technique but the second subtree mount attempt
> >would fail because you can't temporarily remount the device because the
> >mount point is gone.
>
> Why is it gone?
>
> mount /dev/md1 /tmpmnt
> mount --bind /tmpmnt/var /var
> mount --bind /tmpmnt/home /home
>
> Is perfectly fine, and /tmpmnt is still alive and mounted. Additionally,
> you can
>
> umount /tmpmnt
>
> now, which leaves only /var and /home.
i was trying to come up with a userland-only change in mount(8) which
would behave like so:
# mount --subtree var /dev/md1 /var
internally mount does:
- mount /dev/md1 /tmpmnt
- mount --bind /tmpmnt/var /var
- umount /tmpmnt
# mount --subtree home /dev/md1 /home
internally mount does:
- mount /dev/md1 /tmpmnt
- mount --bind /tmpmnt/home /home
- umount /tmpmnt
but that second mount would fail because /dev/md1 is already mounted
(but the mount point is gone)...
it certainly works if i issue the commands individually as i described
-- but a change within mount(8) would have the benefit of working with
/etc/fstab too.
-dean
On Dec 28 2007 22:02, dean gaudet wrote:
>
>i was trying to come up with a userland-only change in mount(8) which
>would behave like so:
>
># mount --subtree var /dev/md1 /var
> internally mount does:
> - mount /dev/md1 /tmpmnt
> - mount --bind /tmpmnt/var /var
> - umount /tmpmnt
>
># mount --subtree home /dev/md1 /home
> internally mount does:
> - mount /dev/md1 /tmpmnt
> - mount --bind /tmpmnt/home /home
> - umount /tmpmnt
>
>but that second mount would fail because /dev/md1 is already mounted
>(but the mount point is gone)...
I do not think it would fail. Like this:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/home 208486056 158605472 49880584 77% /home
# mount /dev/mapper/home /mnt
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/home 208486056 158605472 49880584 77% /home
/dev/mapper/home 208486056 158605472 49880584 77% /mnt
dean gaudet wrote:
> On Wed, 19 Dec 2007, David Newall wrote:
>
>> Mark Lord wrote:
>>
>>> But.. pity there's no mount flag override for smaller systems,
>>> where bind mounts might be more useful with link(2) actually working.
>>>
>> I don't see it. You always can make hard link on the underlying filesystem.
>> If you need to make it on the bound mount, that is, if you can't locate the
>> underlying filesystem to make the hard link, you can use a symbolic link.
>>
>
> i run into it on a system where /home is a bind mount of /var/home ... i
> did this because:
>
> - i prefer /home to be nosuid,nodev (multi-user system)
>
Whatever security /home has, /var/home is the one that restricts because
users can still access their files that way.
> - i prefer /home to not be on same fs as /
> - the system has only one raid1 array, and i can't stand having two
> writable filesystems competing on the same set of spindles (i like to
> imagine that one fs competing for the spindles can potentially result
> in better seek patterns)
> ...
> - i didn't want to try to balance disk space between /var and /home
> - i didn't want to use a volume mgr just to handle disk space balance...
>
Pffuff. That's what volume managers are for! You do have (at least)
two independent spindles in your RAID1 array, which give you less need
to worry about head-stack contention. You probably want different mount
restrictions on /home than /var, so you really must use separate
filesystems. LVM is your friend.
But with regards to bind mounts and hard links: If you want to be able
to hard-link /home/me/log to /var/tmp/my-log, then I see nothing to
prevent hard-linking /var/home/me/log to /var/tmp/my-log.
I think it's possible to be too precious about preserving the illusion
of one file-system structure when the reality is something different.
Don't lose site of reality.
On Sat, 29 Dec 2007, David Newall wrote:
> dean gaudet wrote:
> > On Wed, 19 Dec 2007, David Newall wrote:
> >
> > > Mark Lord wrote:
> > >
> > > > But.. pity there's no mount flag override for smaller systems,
> > > > where bind mounts might be more useful with link(2) actually working.
> > > >
> > > I don't see it. You always can make hard link on the underlying
> > > filesystem.
> > > If you need to make it on the bound mount, that is, if you can't locate
> > > the
> > > underlying filesystem to make the hard link, you can use a symbolic link.
> > >
> >
> > i run into it on a system where /home is a bind mount of /var/home ... i did
> > this because:
> >
> > - i prefer /home to be nosuid,nodev (multi-user system)
> >
>
> Whatever security /home has, /var/home is the one that restricts because users
> can still access their files that way.
yep. and /var is nosuid,nodev as well.
> > - i prefer /home to not be on same fs as /
> > - the system has only one raid1 array, and i can't stand having two
> > writable filesystems competing on the same set of spindles (i like to
> > imagine that one fs competing for the spindles can potentially result
> > in better seek patterns)
> > ...
> > - i didn't want to try to balance disk space between /var and /home
> > - i didn't want to use a volume mgr just to handle disk space balance...
> >
>
> Pffuff. That's what volume managers are for! You do have (at least) two
> independent spindles in your RAID1 array, which give you less need to worry
> about head-stack contention.
this system is write intensive and writes go to all spindles, so you're
assertion is wrong. a quick look at iostat shows the system has averaged
50/50 reads/writes over 34 days. that means 50% of the IO is going to
both spindles.
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.96 2.24 33.65 33.16 755.50 465.45 36.55 0.56 8.43 5.98 39.96
> You probably want different mount restrictions
> on /home than /var, so you really must use separate filesystems.
not sure why you think i want different restrictions... i'm running fine
with nosuid,nodev for /var.
the main worry i have is some user maliciously hardlinks everything
under /var/log somewhere else and slowly fills up the file system with
old rotated logs. the users otherwise have quotas so they can't fill
things up on their own. i could probably set up XFS quota trees (aka
"projects") but haven't gone to this effort yet.
> LVM is your friend.
i disagree. but this is getting into personal taste -- i find volume
managers to be an unnecessary layer of complexity. given i need quotas for
the users anyhow i don't see why i should both manage my disk space via
quotas and via an extra block layer.
>
> But with regards to bind mounts and hard links: If you want to be able to
> hard-link /home/me/log to /var/tmp/my-log, then I see nothing to prevent
> hard-linking /var/home/me/log to /var/tmp/my-log.
you probably missed the point where i said that i was surprised i couldn't
hardlink across the bind mount and actually wanted it to work.
-dean
dean gaudet wrote:
>> Pffuff. That's what volume managers are for! You do have (at least) two
>> independent spindles in your RAID1 array, which give you less need to worry
>> about head-stack contention.
>>
>
> this system is write intensive and writes go to all spindles, so you're
> assertion is wrong.
I don't know what you think I was asserting, but you were wrong. Of
course I/O is distributed across both spindles. You would expect no
less. THAT is what I was telling you.
> the main worry i have is some user maliciously hardlinks everything
> under /var/log somewhere else and slowly fills up the file system with
> old rotated logs. the users otherwise have quotas so they can't fill
> things up on their own. i could probably set up XFS quota trees (aka
> "projects") but haven't gone to this effort yet.
>
See, this is where you show that you don't understand the system. I'll
explain it, just once. /var/home contains home directories. /var/log
and /var/home are on the same filesystem. So /var/log/* can be linked
to /var/home/malicious, and that's just one of your basic misunderstandings.
>> LVM is your friend.
>>
>
> i disagree. but this is getting into personal taste -- i find volume
> managers to be an unnecessary layer of complexity.
Right... But wanting to change the semantics of link(2), so that you can
do something that you already can do, anyway, this is simple, is it?
> you probably missed the point where i said that i was surprised i couldn't
> hardlink across the bind mount and actually wanted it to work.
>
No. Look, you obviously haven't read what I've told you. I mean, it's
very obvious you haven't. I'm wasting my time on you and I'm now out of
generosity. Good luck to you. I think you need it.
And no, you can't change link(2). You don't need to.
On Sun, 30 Dec 2007, David Newall wrote:
> dean gaudet wrote:
> > > Pffuff. That's what volume managers are for! You do have (at least) two
> > > independent spindles in your RAID1 array, which give you less need to
> > > worry
> > > about head-stack contention.
> > >
> >
> > this system is write intensive and writes go to all spindles, so you're
> > assertion is wrong.
>
> I don't know what you think I was asserting, but you were wrong. Of course
> I/O is distributed across both spindles. You would expect no less. THAT is
> what I was telling you.
are you on crack?
it's a raid1. writes go to all spindles. they have to. by definition.
reads can be spread around, but writes are mirrored.
>
> > the main worry i have is some user maliciously hardlinks everything
> > under /var/log somewhere else and slowly fills up the file system with
> > old rotated logs. the users otherwise have quotas so they can't fill
> > things up on their own. i could probably set up XFS quota trees (aka
> > "projects") but haven't gone to this effort yet.
> >
>
> See, this is where you show that you don't understand the system. I'll
> explain it, just once. /var/home contains home directories. /var/log and
> /var/home are on the same filesystem. So /var/log/* can be linked to
> /var/home/malicious, and that's just one of your basic misunderstandings.
yes you are on crack.
i told you i understand this exactly. it's right there in the message
sent.
> No. Look, you obviously haven't read what I've told you. I mean, it's very
> obvious you haven't. I'm wasting my time on you and I'm now out of
> generosity. Good luck to you. I think you need it.
you're the idiot not actually reading my messages.
-dean
On Sat, 29 Dec 2007 12:40:47 PST, dean gaudet said:
> > See, this is where you show that you don't understand the system. I'll
> > explain it, just once. /var/home contains home directories. /var/log and
> > /var/home are on the same filesystem. So /var/log/* can be linked to
> > /var/home/malicious, and that's just one of your basic misunderstandings.
>
> yes you are on crack.
>
> i told you i understand this exactly. it's right there in the message
> sent.
So... You understand that if /var/home and /var/log are on one file system,
you can hard-link, and you set your system up knowing that, and then you're
*surprised* that:
> the main worry i have is some user maliciously hardlinks everything
> under /var/log somewhere else and slowly fills up the file system with
> old rotated logs.
"Doctor, it hurts when I do this.." "Well, don't do that then".
I think the first time I saw the recommendation "Put /home on its own
filesystem and don't give users directly writable directories on /var (except
via set-uid helpers) so they can't play hardlink games" back in 1983 or so.
I know that when SunOS 3.1 came out, that was already well-understood basic
sysadmining. Sometimes, there's actual good reasons behind 20-year-old
voodoo.. ;)
You sure you don't want to redesign your filesystem layout so you don't
have to worry about your malicious users hardlinking stuff? Might be a lot
easier than trying to get the kernel to do what you want in this case....
On Sat, 29 Dec 2007, [email protected] wrote:
> On Sat, 29 Dec 2007 12:40:47 PST, dean gaudet said:
>
> > the main worry i have is some user maliciously hardlinks everything
> > under /var/log somewhere else and slowly fills up the file system with
> > old rotated logs.
>
> "Doctor, it hurts when I do this.." "Well, don't do that then".
actually it doesn't hurt. i have other mechanisms which would pick this
up fairly quickly.
-dean