Re: RFC: permit link(2) to work across --bind mounts ?

Re: RFC: permit link(2) to work across --bind mounts ?

[linux]

> 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.

Re: RFC: permit link(2) to work across --bind mounts ?

[Mark Lord]

linux@horizon.com 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

Re: RFC: permit link(2) to work across --bind mounts ?

[Bodo Eggert]

Al Viro <viro@ftp.linux.org.uk> 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?

Re: RFC: permit link(2) to work across --bind mounts ?

[Al Viro]

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?

Re: RFC: permit link(2) to work across --bind mounts ?

[Johannes Weiner]

Hi Al,

Al Viro <viro@ftp.linux.org.uk> 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

Re: RFC: permit link(2) to work across --bind mounts ?

[Mark Lord]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[Bodo Eggert]

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

RFC: permit link(2) to work across --bind mounts ?

[Mark Lord]

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))

Re: RFC: permit link(2) to work across --bind mounts ?

[Mark Lord]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[Al Viro]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[Al Viro]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[Mark Lord]

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);

Re: RFC: permit link(2) to work across --bind mounts ?

[David Newall]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[Mark Lord]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[David Newall]

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?

Re: RFC: permit link(2) to work across --bind mounts ?

[dean gaudet]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[Jan Engelhardt]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[dean gaudet]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[Jan Engelhardt]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[David Newall]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[dean gaudet]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[David Newall]

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.

Re: RFC: permit link(2) to work across --bind mounts ?

[dean gaudet]

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

Re: RFC: permit link(2) to work across --bind mounts ?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

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....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: RFC: permit link(2) to work across --bind mounts ?

[dean gaudet]

On Sat, 29 Dec 2007, Valdis.Kletnieks@vt.edu 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

Re: RFC: permit link(2) to work across --bind mounts ?

[Rogelio M. Serrano Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 310 bytes --]

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.


[-- Attachment #1.2: rogelio.vcf --]
[-- Type: text/x-vcard, Size: 333 bytes --]

begin:vcard
fn:Rogelio M. Serrano Jr
n:M. Serrano Jr;Rogelio
org:SMSG Communications Philippines;Technical Department
adr:;;;;;;Republic of the Philippines
email;internet:rogelio@smsglobal.net
title:Programmer
tel;work:+6327534145
tel;home:+6329527026
tel;cell:+639209202267
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]