Re: kauth_getuid returns 0?
Re: kauth_getuid returns 0?
- Subject: Re: kauth_getuid returns 0?
- From: Michael Smith <email@hidden>
- Date: Tue, 16 May 2006 19:14:00 -0700
Russ,
It is not safe to assume that the UID in force when a descriptor
(socket) is created is the same UID that will be applicable to all
operations on that socket. If it matters to you on a per-operation
basis who is performing the operation, then it is necessary for you
to work out how to get hold of the caller's identity.
= Mike
On May 16, 2006, at 4:59 PM, Russ Seehafer wrote:
Thanks for your input, this makes a lot of sense now. In the
tcplognke sample, the tcplognke.c file has a method named
tl_attach_fn that makes a call to kauth_getuid(). Is it safe to
assume that when the socket filter is being attached and the call
to tl_attach_fn is made that this specific call to kauth_getuid()
will return the correct user id (of the associated user-space
process)?
If that is the case I think I can solve my problem by storing the
kauth_getuid() value and referencing throughout the rest of the nke
as needed.
Thanks,
Russ
On May 12, 2006, at 9:06 PM, Terry Lambert wrote:
To elaborate on what Brian said.
kauth_getuid() returns the UID of the currently running thread, if
there is one. Otherwise it returns the uid of the currently
running process.
In practice, there are a number of cases where operations are
enqueued into a work queue for later operation. In general, if
the credential is important, then a reference is enqueued as part
of the metadata on the operation being performed. This is then
used as the credential by the proxy operation.
The credential you should use in your code depends on whether the
operation is occurring in a proxy context, or it's occurring in
the real context - in other words, if you are being called into
from a worker thread, it's likely you are being passed a
credential as one of your arguments, or as part of the metadata
for the work item in scope at the time of the call, and there will
either be an accessor function for this, or (worst case) the
structure internals will be visible and you can dereference to get
it yourself.
In other words, blindly calling kauth_getuid() is not necessarily
the right thing to do in all cases.
For an NKE, in general, work will come in on a worker thread when
being pushed up the TCP stack, and the credential you will want to
use for the operation is based on the process associated with the
socket to which the data is destined, not the currently running
thread. Most likely you are either not using this information, or
you don't have the information in scope because you are trying to
perform your operation at the wrong layer.
If you need more help, some of the networking guys read this list,
but you will likely need to tell them more about what you are
doing and when (what's getting hooked, what you are trying to
accomplish, etc.) for them to help you.
If this information is sensitive, and not suitable for a public
list, you should probably work through bugreporter or DTS.
-- Terry
On May 11, 2006, at 8:30 PM, Brian Bergstrand wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On May 11, 2006, at 9:28 PM, Russell Seehafer (RIT Student) wrote:
Hi,
I have a nke that keeps track of its associated user space
clients based on the value returned from kauth_getuid() I have
run into some instances where this call returns 0. I cannot find
any documentation on this method does anyone have any idea what
could be causing this call to return 0? My understanding is that
if a packet is being transmitted by safari, for example, that
kauth_getuid() would return the user's id of the user that is
running safari. Is there more I should consider when using this
method?
Thanks!
Russ
0 is a valid UID. It is the UID of the root user. 0 could also be
returned because there is no current task at the point you call
kauth_getuid() so you are getting the root user by default (ie
the kernel task).
HTH.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFEZAFTedHYW7bHtqIRAv2XAJ9Gny13NuUFYFNx0BSHsLXXC8NshQCg1mrF
/VozuSFlTTBia/GT0p26xis=
=4446
-----END PGP SIGNATURE-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden