Re: What's eating gilbert pid? (kevent NOTE_FORK and pids question)
Re: What's eating gilbert pid? (kevent NOTE_FORK and pids question)
- Subject: Re: What's eating gilbert pid? (kevent NOTE_FORK and pids question)
- From: Derrick Brashear <email@hidden>
- Date: Wed, 24 Feb 2010 16:47:48 -0500
On Fri, Feb 19, 2010 at 3:25 PM, Derrick Brashear <email@hidden> wrote:
> On Fri, Feb 19, 2010 at 3:17 PM, Terry Lambert <email@hidden> wrote:
>> On Feb 19, 2010, at 11:59 AM, Derrick Brashear wrote:
>>>
>>> That's also not really "better". Alas, what I really want to do is
>>> track processes in some way such that marking a process causes that
>>> mark to be inherited by children, and allow the kernel to read the
>>> mark, and a process can cause itself to get a new mark which will be
>>> inherited to *its* future children, and it seems that's simply not
>>> possible:
>>>
>>> -The MAC subsystem isn't supported
>>> (http://developer.apple.com/mac/library/qa/qa2007/qa1574.html)
>>> -login contexts and audit sessions are one-per-process and owned by
>>> system software
>>> -I'm insufficiently special to use a mach special port (there are 7)
>>> -The kauth external cred resolver interface allows but a single
>>> resolver and I'm not memberd.
>>
>> What actor needs access to the information?
>
> A kernel extension will decide which credentials to use based on the
> information. (OpenAFS, in this case)
>
>> (1) This is what the keychain mechanism gives you
>
> The goal is to within, say, a login session, give away the session I
> have and enroll in a new one. This should ideally affect only me, so,
> how I do this without causing the user to lose access to their
> keychain? (I assume this would be with setlcid and using that would
> seem to have this side effect)
There also appears to be no exported method to check a process' login
context from the kernel?
>> (2) Consider adding a directory services plugin, which give you access as
>> part of the authority of memberd
>
> That may be plausible.
I am looking harder at this, I think I need test coe. My only option
seems to be this: the other idea I had, involving mach port
inheritance, fails because you can unenroll yourself from a group by
closing your port without getting a new group, and the goal would be
for every process to be in some group once it's in any.
>> (3) Consider simply putting the initail process in an additional
>> supplementary group
>
> That's fixed, though. Every login session would be an initial process
> (so if I ssh in more than once, each sshd should be treated as
> disjoint; If I am also a console user, that's also disjoint)
Also, if it weren't fixed, it wouldn't survive an initgroups. This
code actually used to just use 2 supplementary groups, but hook
initgroups in the syscall table and put back the groups it added. Yes,
I know it's ugly. I didn't write it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden