Re: [PATCH] Initial support for struct vfs_cred [0/1]

Luca Barbieri (ldb@ldb.ods.org)
09 Sep 2002 00:04:03 +0200


--=-IqWBLD7I9H87daz6IRnA
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

> Now if this is a multithreaded application that does this in one thread
> and another thread happens to open a completely unrelated file around
> the time that the first thread drops this application's setuid
> permissions. If we don't use a copy during the open upcall, but copy it
> after the fact, we don't have the correct permissions around the time
> the file is closed.
You would copy them during the filesystem open.
My point was that in the generic vfs open there is no need to use copied
credentials so credentials copying can be restricted to network
filesystems with not-very-good designs.

> > BTW, imho a correctly designed network filesystem should have a single
> > stateful encrypted connection (or a pool of equally authenticated ones)
> > and credentials (i.e. passwords) should only be passed when the user
> > makes the first filesystem access. After that the server should do
> > authentication with the OR of all credentials received and the client
> > kernel should further decide whether it can give access to a particular
> > user.
>
> Right, which is pretty close to what Coda does.
This is in contradiction with your statement about credentials sent
during close.
The advantage of the model I described is that, with the exception of
connection management, it works exactly like a normal filesystem with
the exception of some totally inaccessible files due to server access
denies.

--=-IqWBLD7I9H87daz6IRnA
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9e8lTdjkty3ft5+cRAkiRAJ99fce/O8dXinxSzBRPHmOS1KPZVQCfZ0ce
um1mSnZ+02x6AFMQ7Rnp+Pw=
=f/xm
-----END PGP SIGNATURE-----

--=-IqWBLD7I9H87daz6IRnA--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/