Jan Kara <jack@suse.cz> writes:

quoted text
>
>> However I'm still confused about the use of current->user.  If that
>> is what we really want and not the user who's quota will be charged
>> it gets to be a really trick business, because potentially the uid
>> we want to deliver varies depending on who opened the netlink socket.
>   I see it's a complicated matter :). What I need to somehow pass to
> userspace is something (and I don't really care whether it will be number,
> string or whatever) that userspace can read and e.g. find a terminal
> window or desktop the affected user has open and also translate the
> identity to some user-understandable name (average user Joe has to
> understand that he should quickly cleanup his home directory ;).
>   Thinking more about it, we could probably pass a string to userspace in
> the format:
>   <namespace type>:<user identification>
>
> So for example we can have something like:
>   unix:1000 (traditional unix UIDs)
>   nfs4:joe@machine
>
> The problem is: Are we able to find out in which "namespace type" we are
> and send enough identifying information from a context of unpriviledged
> user?

Ok.  This provides enough context to understand what you are trying to do.
You do want the unix user id, not the filesystem notion.  Because you
are looking for the user.

So we have to figure out how to do the hard thing which is look at
who opened our netlink broadcast see if they are in the same user
namespace as current->user.  Which is a pain and we don't currently
have the infrastructure for.

Eric
-
unsubscribe notice
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/