Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Jun 2001 19:12:45 -0700
From:      Mike Smith <msmith@freebsd.org>
To:        Pat Dirks <pwd@apple.com>
Cc:        FreeBSD-Arch@freebsd.org, FreeBSD-FS@freebsd.org
Subject:   Re: Support for pivot_root-like system call? 
Message-ID:  <200106090212.f592Cjb02166@mass.dis.org>
In-Reply-To: Your message of "Fri, 08 Jun 2001 14:27:04 PDT." <200106082127.OAA23988@scv1.apple.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

Just a couple of observations about this approach:

 - If you only replace the / mount, you only protect /.  If an 
   application traverses off / onto another filesystem during a lookup,
   the eventuating vnode is going to get the vfsops pointer for the
   filesystem handling the FS the lookup terminates on, circumventing
   the protection.

   A better approach will probably be to implement a 'mount template', 
   where an FS can register a hook which allows it to decide whether if
   wants to be automagically layered over another FS being mounted, 
   something like an automatic version of Terry's union mount.

 - There's an ugly tradeoff between kernel footprint and performance
   here.  You want the checker in kernel space to avoid context switching 
   and piping all your I/O to/from userspace, but if you're doing 
   dictionary searches, that's stuff that is going to be sitting 
   permanently mapped. 8(

Hope this helps; thanks for raising the issue, it's an interesting one. 8)

Regards,
Mike


-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106090212.f592Cjb02166>