August 2010 - Darwin-kernel

Re: Current active login session
by Antoine Missout 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Am I missing something or can't I just check who owns /dev/console ? http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html "The console user is the user whose GUI login session is using the console. The console device, /dev/console, is owned by the console user." Seems simple enough... - Antoine On Aug 20, 2010, at 8:45 AM, Quinn The Eskimo! wrote: > >> If it was possible to get the answer in another manner directly from the daemon without relying on the agents, that'd be much better. > > Not in any well supported fashion. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Antoine Missout 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Unfortunately, this lists all logged-in user using a GUI session, but won't tell which one is currently active/front. - Antoine On Aug 20, 2010, at 10:09 PM, Dave Keck wrote: > I use the utmpx APIs to determine the existing console users from a > daemon process; see the UTXplorer example (which I believe Quinn > wrote?). > > ========== > > #import <utmpx.h> > > - (NSSet *)userNamesForExistingUserSessions > { > > struct utmpx *currentEntry = nil; > NSMutableSet *result = nil; > > result = [NSMutableSet set]; > > setutxent(); > > while (currentEntry = getutxent()) > { > > /* Verify that we have a user and that currentEntry's session is a GUI ('console') session */ > > if (currentEntry->ut_type == USER_PROCESS && !strcmp(currentEntry->ut_line, "console")) > [result addObject: [NSString stringWithUTF8String: currentEntry->ut_user]]; > > } > > endutxent(); > > return result; > > } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Dreamcat4 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=1gVWmlyLEpQD3dQmB43N768SHMIA/X70rqA3kOPNMLs=; b=L9Baw4+9K8qgSfHYjFriXXpN84Dy0IYMPldKPt14lmTHnTdwRzMowK3VbTzCZSVt2t /R1dHQnzFHocJMTVupvARm8E5ACmaIqQi4XBfkOpUvL90SWnjB2jRvMIyoPqQPpNaxJZ 8Y/Y/FiwK3gER9ESIEIO3STqPTZkBucr+xNus= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Q6KTIDSFJ0BVqF7liWIevENS90RM8cjyoTKcxejh6asODqYOFDa+AwwoMo4sWR/kZ/ S5OYcJXKfcJnpP4YiYysN3MII23kyzo7vw7NBNUggPHiIjmvrH8wTzl08xy7HbOHoHK6 LnT3SIhTz4myG7JvJFFC3bzD0a9lU1U9YCM6Y= On Sat, Aug 21, 2010 at 3:09 AM, Dave Keck <davekeck(a)gmail.com> wrote: > I use the utmpx APIs to determine the existing console users from a > daemon process; see the UTXplorer example (which I believe Quinn > wrote?). > > ========== > > #import <utmpx.h> > > - (NSSet *)userNamesForExistingUserSessions > { > > struct utmpx *currentEntry = nil; > NSMutableSet *result = nil; > > result = [NSMutableSet set]; > > setutxent(); > > while (currentEntry = getutxent()) > { > > /* Verify that we have a user and that currentEntry's session is a > GUI ('console') session */ Sorry, does this return only the user active in the foreground (visible window)? Or the list of all users (currently active or not) in fast user switching? > > if (currentEntry->ut_type == USER_PROCESS && > !strcmp(currentEntry->ut_line, "console")) > [result addObject: [NSString stringWithUTF8String: > currentEntry->ut_user]]; > > } > > endutxent(); > > return result; > > } > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/dreamcat4%40gmail.com > > This email sent to dreamcat4(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Antoine Missout 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thanks Dave for the code example, seems like what I need. On Aug 20, 2010, at 10:03 PM, Michael Smith wrote: > On Aug 20, 2010, at 6:34 AM, Antoine Missout wrote: > >> We mean to allow, if the user wants to, to redirect questions about connections made by those processes to be redirected to the current logged-in (admin) user. > > > This means you need to trust the agent quite a lot; you need to trust that it's presented the question and sent the correct reply, just for starters. If a user breaks its own agent by playing with it, he might end up with unwanted rules only for himself. If he's an admin, he might additionally create unwanted rules for network access of daemons. An admin can make any rule anyway. A maliciously crafted answer won't affect the daemon. On Aug 21, 2010, at 12:00 AM, James C wrote: > Antoine, what's the connection between the user agent and the daemon? > If it's TCP, have you considered ident (RFC 1413)? Else faking up > something equivalent out of something like lsof? The agent and daemon talks through mach rpc, allowing us to use ServerAuditToken with audit_token_to_au32 to verify credentials of the agent. - Antoine _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by James C 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=BjvFNs1r/oVq93ZkErnnZuShpS4PBB/njCXajNmq69c=; b=K1iroQ+fJngUH/vKYC/f0wUkfn3oyff2tLWD1Fj9zHYwASB3zyDBlhPNZQ0Qpxxf7o z8DBb65ehuRpF74MgirQtqLKoX3MwNhN9zcTRNXWq4U267H0e60y0sQ7lVWd/lfjIgIi Ie2qD9jD8kFSeuvuOsZQCN2CWc4xWO2ZF7VsE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=DJNW3pakPe1K34etxrHajjhGxW8OKJIZ1VjAn/kQZ9pxRsC915hOsAijvv8PYru0g3 DI3MWu6m2NZ6YfZEkGWUQ0CvgCfSfQNy1cpgLesgwhNrvC5nUiIaaeKdpjd7EVr8U8sV mN0AdWc3y2hs99euP+NjfHTjZLYtoJUXWhnuo= Antoine, what's the connection between the user agent and the daemon? If it's TCP, have you considered ident (RFC 1413)? Else faking up something equivalent out of something like lsof? Quinn, my MacOS 10.5.8 machine is not running an ident daemon. Does Apple have a preferred implementation? Regards, James. > Message: 11 > Date: Fri, 20 Aug 2010 09:34:03 -0400 > From: Antoine Missout <antoine.missout(a)metakine.com> > Subject: Re: Current active login session > To: darwin-kernel(a)lists.apple.com > Message-ID: <8E24EDF6-F942-4593-97D8-A5B672AAFED1(a)metakine.com> > Content-Type: text/plain; charset=us-ascii > > I knew this was coming ;) > > We police network connection in a similar manner to Little Snitch. Network connections can be either denied, allowed, or up to the user to decide in an interactive manner. > > For a given process making a connection, we ask the corresponding user that owns the process. However, no logged-in users owns daemon or anything above a login session. > > We mean to allow, if the user wants to, to redirect questions about connections made by those processes to be redirected to the current logged-in (admin) user. > > > - Antoine > > > > > On Aug 20, 2010, at 9:06 AM, Quinn The Eskimo! wrote: > >> On 20 Aug 2010, at 14:02, Antoine Missout wrote: >> >>> It currently is 'not at all', but it seems I'll be forced to switch to 'as little as possible' to know the current active login, unless you can point me to something not well supported. >> >> Right. But what decisions does your daemon make based on the current active login? >> >> S+E >> -- >> Quinn "The Eskimo!" <http://www.apple.com/developer/> >> Apple Developer Relations, Developer Technical Support, Core OS/Hardware >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-kernel/antoine.missout%40meta… >> >> This email sent to antoine.missout(a)metakine.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Dave Keck 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=CuMTGnXQHNq+j66h1yHV3rLpoPhdTaWlwnkJKCd5c0Q=; b=fSOveSfRQ9/3rV+izv+upoc8ppcaB1lNeBvqUjyIcwfV3j49w06aBmWN80SLpZBVAG hE1nNLhlm00s57O0Q7J8aqednyOr82bEAZR4fxeU7qUpTwIhxvkhZG+xHhDnfDvERZq+ 9ZipAV2/isBNxWEjTPd0p28uMPu34e98mfSIg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=LoWmZZ29x+McHAJARUjk1zicufDVkrRmhTtHYY9tcyIxWrQoN79YfwAcEn+VfdvM8E o0heMOXrbBrBuK0Vd8mTOe54FW7W3MBSODrDIax5iBHP/CBR7Cd0H3YvaRpiwnRc2bdK Dud8J/iBT6kdnUU1i6SLaAeu96iWYpGT8J+wU= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Michael Smith 21 Aug '10

21 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to kill a kqueue camper thread? Was: close() hangs … in 10.5 only
by Terry Lambert 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 20, 2010, at 4:35 AM, Jerry Krinock wrote: > On 2010 Aug 20, at 01:28, Terry Lambert wrote: >>> Why not have a timeout on the kevent… >> >> This is _a_ way, but your timeout would need to be tight to ensure that it was more or less responsive… > > Actually I could do that, since this is just to clean up resources; no hurry. But then there's that "elegance" thing. "Polling", anyone? Seems like it defeats the purpose of kqueue. > >> Alternately, the NSThread in 10.5.x is based on a pthread, so you could do: >> volatile pthread_t kqueue_thread; >> // called within the thread before looping >> kqueue_thread = pthread_self(); > > Yes, this is one of your previous suggestions, to have the secondary thread feed back its thread ID. I kind of like your first suggestion better, to get the thread ID from pthread_create(). Warning: I've never done this – just reading docs. But I'll get it one way or the other. The suggestion was made on the basis of incomplete information, which is why I gave a shotgun answer to cover all possible bases, given your observed behaviour. I wouldn't suggest throwing out NSThread and object encapsulation over this. >> There's no guarantee that future versions of NSThread will be based on the same primitives, but you can be pretty sure that there's not going to be a change in that regard in a 10.5.x, so as long as you check your OS version at runtime … > > Terry, I believe you're suggesting that I execute my current code for 10.6+, which relies on the fact that when I EV_DELETE a kqueue from the main thread, kevent() on the secondary thread returns -1 with errno=EINTR immediately. Yes. > Certainly this is a very welcome new feature! But is it by design? Will it work in 10.7+? Where is it documented? If you're sure it's in there for keeps I shall happily file feedback to Apple on the documentation. I can't make forward looking statements about things like that. It works that way by design in 10.6.x. You could always ask for a documentation change to try and tie our hands in future versions. I tend to like to keep documented interface contracts to a minimum in man pages I work on, though, so as to not preclude doing something clever in the future; being with the IEEE, you can probably appreciate that, since POSIX says nothing about close(2) triggering cancellation of outstanding I/O operations vs. blocking until those operations complete. Writing code that depends on cancellation is therefore non-POSIX code which depends on implementation-defined behaviour. - A.M. has suggested a "quit pipe". I would recommend against it. This is where you add a socketpair(2) or a pipe(2) system call to get a connected descriptor pair, and then add it as another event source which is monitored by your camping thread. When you want to quit, you write a byte down the pipe or socket, the kevent for the pipe fires in the worker thread, it wakes up, and quits because of the fact of the message, or its contents. I may even have suggested this to A.M. as a solution to a previous problem. This method has been used with select, and to implement a "select" via pipes and processes on systems without select (e.g. pre-BSD4.1g UNIX systems, like pre-modern Altos Xenix, Sun 3, and so on, systems). The negative thing about that approach is that what we are trying to do here is work around a 10.5 issue that doesn't exist in 10.6, and it's moderately invasive and error prone. Here are the reasons I'd personally prefer to use a signal: (1) You can set up the signal sender after the signal thread because of the asynchronous initialization of the global; otherwise, it's all setup work. (2) The approach consumes two file descriptors; your default per-process limit is 256. (3) A close of the fd on the sender end could happen as a result of a framework; a global integer (pthread_t) is less likely to be stomped. (4) A close of the fd on the sender will trigger an EOF condition, but not a read-ready condition, if you haven't asked for that notification, so it's somewhat error prone. (5) This is throw-away code, and the approach is less invasive of your future versions if you use a signal. (6) The signal can be targetted to a specific thread (7) There's no danger of accidental or intentional interception of a thread-directed signal (well, without setting up a mach special port handler for the thread, anyway). I think the benefits of async initialization, no additional fd worries, and the mechanism being orthogonal to interfaces you are probably already using is enough of an argument to sell the signal approach. I'd also caution *against* adding the signal itself as a kevent() in the receiver as was suggested, since doing that's not a thread-specific thing at that point: kqueues, being based on file descriptors, are not per-thread. Other kevent() calls could see it -- for example the GCD dispatch thread. That could be bad. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to kill a kqueue camper thread? Was: close() hangs … in 10.5 only
by A.M. 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Aug 20, 2010, at 7:35 AM, Jerry Krinock wrote: > > On 2010 Aug 20, at 01:28, Terry Lambert wrote: > >>> Why not have a timeout on the kevent… >> >> This is _a_ way, but your timeout would need to be tight to ensure that it was more or less responsive… > > Actually I could do that, since this is just to clean up resources; no hurry. But then there's that "elegance" thing. "Polling", anyone? Seems like it defeats the purpose of kqueue. > >> Alternately, the NSThread in 10.5.x is based on a pthread, so you could do: >> volatile pthread_t kqueue_thread; >> // called within the thread before looping >> kqueue_thread = pthread_self(); I use pipes added as kqueue events for inter-thread communications. This also allows for an arbitrarily-sized payload to go along with the events itself (in the form of a pipe message). However, you know that sending a signal to a thread does not have to imply asynchronous behavior, right? You can add the signal to be handled by kqueue as a simple event. In your design, instead of managing the kqueue fd in the main thread, I would hand it to the new thread, and send a cleanup signal via the pipe (or UNIX signal) to the secondary thread to end it. Cheers, M _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Current active login session
by Antoine Missout 20 Aug '10

20 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I knew this was coming ;) We police network connection in a similar manner to Little Snitch. Network connections can be either denied, allowed, or up to the user to decide in an interactive manner. For a given process making a connection, we ask the corresponding user that owns the process. However, no logged-in users owns daemon or anything above a login session. We mean to allow, if the user wants to, to redirect questions about connections made by those processes to be redirected to the current logged-in (admin) user. - Antoine On Aug 20, 2010, at 9:06 AM, Quinn The Eskimo! wrote: > On 20 Aug 2010, at 14:02, Antoine Missout wrote: > >> It currently is 'not at all', but it seems I'll be forced to switch to 'as little as possible' to know the current active login, unless you can point me to something not well supported. > > Right. But what decisions does your daemon make based on the current active login? > > S+E > -- > Quinn "The Eskimo!" <http://www.apple.com/developer/> > Apple Developer Relations, Developer Technical Support, Core OS/Hardware > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/antoine.missout%40meta… > > This email sent to antoine.missout(a)metakine.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0