Re: Detecting login/logout?
Re: Detecting login/logout?
- Subject: Re: Detecting login/logout?
- From: Steve Herman <email@hidden>
- Date: Tue, 4 Nov 2003 12:06:07 -0600
Sorry to take so long replying... didn't get an opportunity to check
my e-mail over the weekend and was swamped yesterday...
Chad, thanks for all the excellent info, it answers my initial
questions very well.
At 2:41 AM -0800 11/1/03, Chad Jones wrote:
[snip]
-----------#3
I've been asked to look at the feasibility of writing a utility that
needs to run _alongside_ the login dialog on OS X.
What problem exactly are you trying to solve? Why does the GUI have
to show up at the login screen and no other time? Also, what Mac OS
X system(s) are you targeting?
Right now I'm targeting 10.2.x. I'm sure 10.3 will be in the picture soon.
I've been asked to investigate implementing a "windows domain
password reset utility" for use by folks that have forgotten their
domain passwords (our Help Desk is inundated with password reset
calls). A large part of this functionality has already been
implemented on our Windows platforms so I'm playing catch up on the
Mac platform.
Right now it's not be critical that it display GUI at the login
screen because the Mac users are logging into a local account and
they could perform the reset by running the app while logged in
locally... however our customers will most likely soon be
authenticating against active directory in which case the user (who
has forgotten his password) won't be able to get onto the machine and
needs to be able to initiate the reset from the login screen.
-----------#5
However, there are some issues with your application being terminated
with the login session that you might need to look at.
Yep. After a logout your application by default will get terminated
(actually killed) by the system. I won't go into why, lets just say
it has to do with a security model/feature inherited from NeXT.
I figure I'm probably looking at a daemon that runs as a StartupItem
and watches login/logout based on the samples you suggested. And
then it starts the interface for doing the reset when no one's logged
in, and stops it when a login occurs.
[snip]
-----------#8
(2) Programs that are launched via the StartupItems mechanism are in a
different Mach bootstrap context than normal processes. When the user
logs in, your program will be killed, because it has created Mach
ports (by linking and using certain CoreFoundation functions) and
those ports will be stale when the new Mach context is brought > forward.
Are you sure the existing context is destroyed? How do normal programs
(e.g. system daemons) survive?
The login context is created when the user logs in and is destroyed
when the user logs out. How system daemons survive is they live in
a separate context (the "startup context" a.k.a. "root context" )
which exists from first startup until the system is shut off.
Note processes in the startup context can't/shouldn't use higher
level frameworks (e.g. Carbon/Cocoa) or risk being killed by the
operating system for reasons I won't go into detail. Let's just say
that the higher-level frameworks sometimes need to talk to certain
parts of the operating system which are only available to user/login
sessions. If the frameworks finds it can't talk to those parts then
the framework will call abort() on the calling process which in the
end puts up the "unexpectedly quit" dialog to the user.
I'm sure I'll have to investigate the above issues too. Any specific
tips or warnings you can offer?
Thanks again for all the good info.
Steve
--
+-------------------------------------------------------+
| Steve Herman |
| Macintosh Software Development and Support |
| Lockheed Martin Information Technology NASA-ODIN |
| 102 Research Blvd, Bldg 2 |
| Madison, AL 35758 (voice) 256 319-2869 |
|
mailto:email@hidden (fax) 256 319-2984 |
+-------------------------------------------------------+
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.