--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 18, 2007 at 12:51:24PM +0100, Hauke Fath wrote:
> Am 17.01.2007 um 21:43 Uhr -0500 schrieb George Georgalis:
> >I'm having trouble writing an /etc/exports file for
> >a read-only mount point. I'd expect it something
> >like:
> >
> >/host/software -maproot=3Dnobody:nobody -ro -network 10/8
> >
> >but on the target host, that yeilds
> >
> >mount_nfs: can't access /host/software: Permission denied
> >
> >while other rw /host/* exports mount fine. What exactly is
> >the syntax for a ro export?
>=20
> Let me guess: The /host/* exports are on the same filesystem?
>=20
> You cannot export directories from one filesystem with differing=20
> credentials (like rw/ro, different access control liste, etc.). A=20
> workaround is to use null mounts, and export those.

The problem with doing this is that you don't really gain much. Maybe we=20
should just turn off the restructions we have.

The problem is that the NFS server code can't tell if a file handle
corresponds to a file under a given mount point or not when you have
multiple exposed mount points in one file system. So say you had one
directory in an fs exposed read-write and another read-only. If an=20
attacker took a file handle from the r/o mount and used it via the r/w=20
mount point, the corresponding file can be modified even though the=20
initial layout would say it wouldn't.

Null mounts don't change this as the file-system-specific part of our file=
=20
handles are the same between a null mount and the underlying file system.=
=20
So given a file handle from the null mount, you can figure out the file=20
handle for the same file for the non-nullfs fs.

Perhaps the solution is to make the code be VERY clear that we will permit=
=20
you to have differing export ability but that the laxest restrictions=20
apply to the whole file system. As in we have the kernel remember the=20
laxest permissions on an export and if you add an additional export that=20
makes the permissions laxer, we emit a kernel warning message. Hmmm...=20
We also probably want to track the tightest too. So if you have a mount=20
exported r/o and add a r/w mount, or if you have a r/w mount and add a r/o=
=20
mount, the kernel mentions that your file system security may not be what=
=20
you expect. Adding a second such mount shouldn't emit a message, though.

Thoughts?

Take care,

Bill

--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFuOYcWz+3JHUci9cRAsVrAJ9m41IGyLixEdBps3HnTBJhR9BllgCfZV6u
MaR4lBatzWPExYmI7/dySuQ=
=zaln
-----END PGP SIGNATURE-----

--d6Gm4EdcadzBjdND--