From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Hudec Subject: Re: [PATCH] private mounts Date: Tue, 10 May 2005 21:15:15 +0200 Message-ID: <20050510191514.GA20035@vagabond> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from cimice4.lam.cz ([212.71.168.94]:20698 "EHLO vagabond.light.src") by vger.kernel.org with ESMTP id S261746AbVEJTPV (ORCPT ); Tue, 10 May 2005 15:15:21 -0400 To: Nir Tzachar Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 10, 2005 at 21:28:25 +0300, Nir Tzachar wrote: > please shout if im missing something, but i think there can be a simple= =20 > solution (which involves quite a bit of coding....). > Why not implement FUSE as a user space applications --> not involving any= =20 > kernel code at all. Yes, you can use the LD_PRELOAD mechanizm to replace the syscalls in libc. I have seen several programs using this technique. They kind-of work, but have their quirks. > what i have in mind is replacing the user space daemon (which FUSE=20 > currently utilizes to speak with the kernel) with a different=20 > daemon. i suggest using a user space nfs daemon, which can than be mounte= d=20 > on the local (or on a remote) machine as a regular nfs exported fs.=20 This *does* involve kernel code -- only such that is already written. I believe this has already been tried. Some programs actually do use it (I believe SFS is one). But NFS is not a good protocol for this. There is also the coda interface. That has also been tried, with a bit better result, but it is not as flexible. > this solution seems to solve the permissions problems and simplifies=20 > things a bit, since no kernel code is needed (apart from allowing user=20 > mounts).=20 > however, implementing this is quit involved, and im sure several hurdles= =20 > must be passed along the way. regardless, i think the benefits can=20 > outweigh such drawbacks..... No, it does not solve anything. The permission problems spring from the requirement that users be able to mount filesystems. It is completely unrelated to how the filesystem is handled in kernel. ---------------------------------------------------------------------------= ---- Jan 'Bulb' Hudec --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgQhCRel1vVwhjGURAlMhAKDI5ft1Sf+vngNqMdb2hNSznghjqgCdE1x+ +iP/1I03yyl1b2s0gpsBfnI= =PmFr -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc--