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: Fri, 19 Feb 2010 15:25:14 -0500
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)
> (2) Consider adding a directory services plugin, which give you access as
> part of the authority of memberd
That may be plausible.
> (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)
--
Derrick
_______________________________________________
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