ugh. rpc.gssd reads root’s .k5identity file. If I put my principal in
/.k5identity, things work. So a plugin would probably work. But it looks like a
bug that should be fixed.
> On Jul 23, 2019, at 10:09 AM, Charles Hedrick wrote:
>
> Maybe there’s a path through the code that I didn’t find.
On Tue, 2019-07-23 at 14:09 +, Charles Hedrick wrote:
> Maybe there’s a path through the code that I didn’t find. But it ends
> up failing if the credential isn’t username@DOMAIN. There’s an
> explicit test. I don’t see why it couldn't specify that in the first
> place.
>
> I think if you
this is worse than it looks. Documentation says that GSSAPI will obey
.k5identity. That’s the right solution for you situation of the laptop user
with a different username.
The problem is that there’s no system-wide equivalent of .k5identity. My code
causes problems, because in specifying a
Maybe there’s a path through the code that I didn’t find. But it ends up
failing if the credential isn’t username@DOMAIN. There’s an explicit test. I
don’t see why it couldn't specify that in the first place.
I think if you want a local user joe to access NFS as jdoe@REALM, you’d want to
set
This matches the observed behavior. What you describe is internally a single
address space, but from a user's point of view KCM: points to a different
address space per user. It means there’s no unambiguous syntax for a root
daemon to refer to a specific user’s collection.
---
On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote:
> The problem is that the code in rpc.gssd works as followers:
>
> * get the default credential from the collection
> * fail unless it’s username@DOMAIN
>
> If you replace the initial step by code telling it explicitly to get
>
