Am 13.03.2015 um 11:27 schrieb Robert Wehn:
...
>
> We think the suexec-security-mechanism to be basically incompatible with
> an (ACL- and Kerberos-based) NFSv4 way of security. The NFSv4 security
> has at least to important parts. nfs(5):
> * Transport: cryptographic proof of a user's identity (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello *
@Brandon, Ben:
On 13.03.2015, 15:05 Brandon Allbery wrote:
> ... the whole business about snooping ticket caches and caching its
> own private copy is concerning security-wise and seems like it
> would easily become confused.
On 13.03.2015, 1
On Mon, 2015-03-16 at 10:33 +0100, Robert Wehn wrote:
> Hello *
>
> @Brandon, Ben:
> On 13.03.2015, 15:05 Brandon Allbery wrote:
> > ... the whole business about snooping ticket caches and caching its
> > own private copy is concerning security-wise and seems like it
> > would easily become confus
Hello,
Simo Sorce wrote:
>> * Is this concealment of user names considered a good idea?
>
> It may be useful
I now realise I didn’t state my purposes:
* the ability of a remote service to configure access to roles/groups, and
leave the assignment of individuals to roles/groups to the sender r
On 03/14/2015 05:10 AM, Rick van Rein wrote:
> I’ve been looking for ways of concealing principal names with Kerberos. I
> think this
> is of interest in relation to Internet-wide realm crossover with Kerberos.
> The only
> way I found are the anonymity mechanisms of RFC 6112, but that provides
