Cheers, I'll consider that. So the client would effectively hand shake with the lower level program and be supplied with a list of permissions which the user has access to.
You mentioned about many systems being multi-user. When the client attempts to connect to the lower machine is it a trivial issue to either supply information on what user the attempt is coming from within the initial communication, or for the low level program to identify where/who the request is coming from? Thanks, Wesley Brooks. On 13/12/06, Tor Hildrum <[EMAIL PROTECTED]> wrote: > On 12/12/06, Tim Golden <[EMAIL PROTECTED]> wrote: > > > But this is all quite Win32-specific (as well as > > being hand-wavingly unspecific). I don't know > > how you'd go about it on *nix but I bet it's nothing > > like the same. > > The same general principle applies. You need to get a > UID or similar from a specific user, or you have to > check all connected TTYs and just pick a random user > out of the users logged in. Most systems today are > multi-user so the notion of 'the user logged in' doesn't > make sense system-wide. > > I think the best way to solve this is to use a client-server > approach. Have a deamon/service run in the background, > and then have a client started at login that pings the server > and notifies it of your presence. > > Tor > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor