Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Mar 2001 11:28:01 -0800
From:      Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Sean Kelly <smkelly@zombie.org>, freebsd-stable@FreeBSD.ORG
Subject:   Re: mountd 
Message-ID:  <200103161928.f2GJSBq05018@cwsys.cwsent.com>
In-Reply-To: Your message of "Wed, 14 Mar 2001 16:33:33 PST." <200103150033.f2F0XXV33398@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200103150033.f2F0XXV33398@earth.backplane.com>, Matt Dillon 
writes:
> :My NFS server has /usr on a single filesystem, yet I would like to share
> :subdirectories of /usr with different attributes.  An example would be:
> :
> :     /usr/ports	       readonly
> :     /usr/src	       readonly
> :     /usr/local/build  read/write
> :
> :The idea is that machines with very little disk space will be able to build
> :ports and source using /usr/build/<hostname> as the workdir.  As I
> :understand it, this can't be done since /usr is a single filesystem on the
> :server and must
> :a) be listed on single line in /etc/exports
> :b) have the same attributes for all exported directories
> 
> :Am I missing something?  If not, why is FreeBSD's mountd implimented this
> :way when it causes severe limitations such as the one I just came across?
> :How hard would it be to reimpliment the system?  Does anybody have any
> 
>     The limitation is not restricted to FreeBSD.  The real problem here is
>     that NFS security is based on file handle identifiers and filesystems.
>     You can export all the subdirectories in a filesystem wholely
>     read-only, or wholely read-write, but not a combination of the two
>     because the NFS server has no idea which subdirectory of that
>     filesystem an NFS client may be accessing... NFS clients access files
>     by file handle id's, NOT by path names.
> 
> :suggestions for a quickfix?  What is the answer to life, the universe, and
> :everything?
> :
> :-- 
> :Sean Kelly         | PGP KeyID: 77042C7B
> :smkelly@zombie.org | http://www.zombie.org
> 
>     No problem.  Here's what you do:  Lets say that /usr is local on all
>     your machines but you want to export /usr/ports and /usr/src from
>     your NFS server read-only.  Simply make /usr/ports/distfiles on your
>     NFS server be a softlink to /usr/ports.distfiles, which will be a local
>     directory on every machine (including the NFS server).
> 
>     Then set the WRKDIRPREFIX variable in your /etc/make.conf on the clients.
>     e.g. mkdir /var/portswork and in /etc/make.conf:
> 
>     WRKDIRPREFIX= /var/portswork
> 
>     (Note: some ports are huge so WRKDIRPREFIX needs to point to somewhere 
>     with a lot of space).
> 
>     Now you can build a port on any client using the /usr/ports exported
>     read-only from the NFS server.  If you are exporting the whole of /usr
>     read-only to the clients, then obviously you have to choose some other
>     directory to hold the distfiles by adjusting the /usr/ports/distfiles
>     softlink.  The softlink must be valid (point to some local directory
>     somewhere) on both the NFS server and all the clients.
> 
>     --
> 
>     In regards to /usr/src and /usr/obj.  What I normally do is export
>     /usr/src AND /usr/obj from the NFS server, both read-only.  I do all
>     builds on the server and then install them from the clients (i.e. I
>     never actually build the world on a client).  Same goes with kernels
>     for the clients... build on the server, install from the client.
> 
> 						-Matt

This is good.  A more generic approach would be to mount the directories you wish to export using nullfs or unionfs -r to another directory, e.g /nfs/<directory>.  Then export /nfs/<directory>.  Of course this depends on nullfs and unionfs not panicking your system.  Other than the bugs in nullfs and unionfs, assuming that the bugs will get fixed one day, does anyone see any problems or security implications with this approach?

-- 
Regards,                         Phone:  (250)387-8437
Cy Schubert                        Fax:  (250)387-5766
Team Leader, Sun/Alpha Team   Internet:  Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC            




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




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