 |
|
| Linux Forum Index » Linux Development - Applications » Session management in Linux (long)... |
|
Page 1 of 1 |
|
| Author |
Message |
| Alan Curry... |
 Posted: Mon Aug 31, 2009 12:05 pm |
|
|
|
Guest
|
In article <71e8aa22-1e69-4843-b299-4d152adcabe3 at (no spam) o9g2000prg.googlegroups.com>,
Bryan Ashby <nuskooler at (no spam) gmail.com> wrote:
Quote: First off, sorry for such a long post -- Hopefully I'm fairly clear on
everything, however 
I'll fill in the missing details with my imagination and then you can correct
the places where it went off course.
Quote:
I am working on porting a application from Windows to Linux. Part of
the application set is a Windows service that is the core of the
logic. The service makes decisions about traffic & processes amongst
other things. To interact with the user, it talks to 0:n agents (e.g.
System tray app on MSW) to do things like prompt (credentials,
overrides, ...) and display notifications.
In other words (unix words) you have a daemon ("service") that can serve
multiple local users, and a client ("agent") that provides a way for users to
interact with it.
Quote:
On MSW, each agent runs in a "Session". That is, it's own desktop. For
example, if user A logs into Windows agent 0 is started and talks to
the service. If user A stays logged in, but user B logs in (for
example through Windows Fast User Switching (FUS) or remotely) agent 1
is started and talks to the service for user B. The service handles
tracking of these sessions and related agents using the Windows
Terminal Services API's (e.g. WTS*() ).
What are the equivalents to these APIs in Linux? For example, Windows
has these concepts:
- Sessions (briefly described above)
- Active session (e.g. Linux controlling terminal I believe -- which
session(s) have a user attached with I/O).
Here's where you may be going the wrong direction. If your client only runs
in the context of a graphical login session, then you can ignore all the
stuff related to tty sessions. Controlling terminal, process group, and the
session ID of a process are all related to ttys (that's text terminals) and
are irrelevant to an X11 session, which may contain many text terminals or
may contain none.
If you intend to have your client operate in both text mode and graphical
mode, the easiest way is probably to make 2 separate client programs, with
the core interface-independent logic being in a library that they both use.
Quote: - Session enumeration such as WTSEnumerateSessions()
I'm imagining... that this is a "get a list of all logged in users" function.
In that case, getutent() may be the closest thing. But it's probably a bad
idea to use it. More on that later.
Quote:
With all of that said, to port to Linux I need to be able to do the
following:
1) Given a process ID:
- Is the process interactive (e.g. is it a console or X process).
I've looked into inspecting the DISPLAY environment variable and
pseudo terminal information using /proc for this)
This sounds like the beginning of an bad plan. You shouldn't be looking at a
foreign process's DISPLAY variable, because that implies you intend to throw
something onto its display directly from the daemon, which is beyond rude.
The client program, started within the user's login session, should be
responsible for the interactive stuff. It is inside the session so it already
has the ability to talk to the user. The daemon should only communicate with
the client. It goes like this:
daemon <---> client <---> display
Not like this:
client <---> display <---> daemon
Quote: - What "session" does the process belong to. I've been researching
this for days and there seem to be various concepts of sessions such
as process groups, sessions, tty's, etc. This is very confusing.
It'll be less confusing once you realize that text login sessions (console,
ssh, xterm, etc.) are a completely separate concept from X11 sessions
(startx, xdm, gdm, kdm, etc.) and you can't use the same code for both.
Quote: - Is the process a user process or daemon? Again for this, I've been
looking at inspecting /proc information and tty info
- Finally, is the process active/a controlling terminal. In other
words, does it have a user attached with I/O or is it inactive (e.g.
When I switch users in X/GNOME/whatever, only one is "active" at time)
I'm giving up here, hopefully something up above will be enlightening. I
think the fundamental error is thinking that a daemon should communicate with
a user by directly manipulating his terminal/display. You've gone a long way
toward learning how to pull this off, but if you do it will be considered
kludgy and evil.
--
Alan Curry |
|
|
| Back to top |
|
|
|
| Bryan Ashby... |
| Posted: Mon Aug 31, 2009 2:54 pm |
|
|
|
Guest
|
On Aug 31, 4:05 pm, pac... at (no spam) kosh.dhis.org (Alan Curry) wrote:
Quote: In other words (unix words) you have a daemon ("service") that can serve
multiple local users, and a client ("agent") that provides a way for users to
interact with it.
Yes. The daemon is the business logic of our application. I'll give a
little bit more details: The short - parental controls. The longer
version - traffic capture device routes interesting traffic to the
daemon for policy enforcement. Any user interaction the daemon asks
the agent for. For example, if no one is logged in the daemon can ask
the agent to prompt a login dialog. This is where knowing what session
(graphical login session) a PID belongs to comes in: The daemon must
ask the appropriate agent to collect credentials (e.g prompt for
login).
Quote: Here's where you may be going the wrong direction. If your client only runs
in the context of a graphical login session, then you can ignore all the
stuff related to tty sessions. Controlling terminal, process group, and the
session ID of a process are all related to ttys (that's text terminals) and
are irrelevant to an X11 session, which may contain many text terminals or
may contain none.
If you intend to have your client operate in both text mode and graphical
mode, the easiest way is probably to make 2 separate client programs, with
the core interface-independent logic being in a library that they both use.
We have to major options here as I see it: 1) Do as described and
create 2 separate programs - one to filter GUI modes, the other for
text modes. 2) Somehow disallow (per policy/user) the use of text
modes. Basically the issue is that parental controls are useless if
all one needs to do is drop to a text mode to get around them (we're
talking more than just web browsing here). Given #2, filtering only
the GUI portions is a great starting point, but you see the problem.
Quote:
- Session enumeration such as WTSEnumerateSessions()
I'm imagining... that this is a "get a list of all logged in users" function.
In that case, getutent() may be the closest thing. But it's probably a bad
idea to use it. More on that later.
WTSEnumerateSessions() enumerates just that: Sessions. Windows has the
concept of separate graphical sessions (e.g. logins). For example (for
illustration purposes), session 0 is generally services, and 1+ are
user login(s).
Quote: This sounds like the beginning of an bad plan. You shouldn't be looking at a
foreign process's DISPLAY variable, because that implies you intend to throw
something onto its display directly from the daemon, which is beyond rude..
The client program, started within the user's login session, should be
responsible for the interactive stuff. It is inside the session so it already
has the ability to talk to the user. The daemon should only communicate with
the client. It goes like this:
daemon <---> client <---> display
Not like this:
client <---> display <---> daemon
See above. The daemon will never interact with a user/graphics
directly. This always happens through the agent. However, the proper
agent must be used. At the daemon/filtering level I have some traffic
and a PID. Given that, I need to ask the appropriate agent to display
GUI/notifications if needed.
Quote: It'll be less confusing once you realize that text login sessions (console,
ssh, xterm, etc.) are a completely separate concept from X11 sessions
(startx, xdm, gdm, kdm, etc.) and you can't use the same code for both.
It's already (I think!) less confusing after reading your post, yes.
Thanks for your quick response. If this post clears things up further
and you have any additional information, I'd love to hear it! |
|
|
| Back to top |
|
|
|
| Bryan Ashby... |
| Posted: Mon Aug 31, 2009 3:52 pm |
|
|
|
Guest
|
| Update: I believe ConsoleKit and related work is what I'm after. |
|
|
| Back to top |
|
|
|
| Rainer Weikusat... |
| Posted: Tue Sep 01, 2009 5:05 am |
|
|
|
Guest
|
pacman at (no spam) kosh.dhis.org (Alan Curry) writes:
Quote: Bryan Ashby <nuskooler at (no spam) gmail.com> wrote:
First off, sorry for such a long post -- Hopefully I'm fairly clear on
everything, however
[...]
Quote: I am working on porting a application from Windows to Linux. Part of
the application set is a Windows service that is the core of the
logic. The service makes decisions about traffic & processes amongst
other things.
[...]
Quote: On MSW, each agent runs in a "Session". That is, it's own desktop.
[...]
Quote: What are the equivalents to these APIs in Linux? For example, Windows
has these concepts:
- Sessions (briefly described above)
- Active session (e.g. Linux controlling terminal I believe -- which
session(s) have a user attached with I/O).
Here's where you may be going the wrong direction. If your client only runs
in the context of a graphical login session, then you can ignore all the
stuff related to tty sessions.
Except that there are no 'tty session' in the way you are envisoning
this and even someone logging into the system via some display manager
still has a 'login session'.
[...]
Quote: - What "session" does the process belong to. I've been researching
this for days and there seem to be various concepts of sessions such
as process groups, sessions, tty's, etc. This is very confusing.
It'll be less confusing once you realize that text login sessions (console,
ssh, xterm, etc.) are a completely separate concept from X11 sessions
(startx, xdm, gdm, kdm, etc.) and you can't use the same code for
both.
It would become even more easier if the OP would simply dump the
Windows-originated idea that 'users' correspond with 'desktops' and
that what is called 'a session' on Windows had any relation to what is
called 'a session' on UNIX(*). A description of what features the
Windows software is using to accomplish what could help here. |
|
|
| Back to top |
|
|
|
| Jan Kandziora... |
| Posted: Fri Sep 04, 2009 4:52 pm |
|
|
|
Guest
|
Bryan Ashby schrieb:
Quote: On Aug 31, 4:05 pm, pac... at (no spam) kosh.dhis.org (Alan Curry) wrote:
In other words (unix words) you have a daemon ("service") that can serve
multiple local users, and a client ("agent") that provides a way for
users to interact with it.
Yes. The daemon is the business logic of our application. I'll give a
little bit more details: The short - parental controls.
If this is the goal, I'd just throw away the whole idea of associating
a "session" to a policy. Linux is multi-user "by nature", and an ordinary
user *never* needs admin access to do his work (or play). So all the
session switching and policy kludges of MS-Windows are irrelevant.
Associate the user id with your policy and you are done with that part of
your task. The kernel will enforce all policies to that user automagically.
You can use file rights, ACLs, iptables, proxys or even SElinux do all the
dirty work. That's what admins have done at any time.
Just make a set of reasonable rules for these already existing tools for the
most used Linux distributions and a comfortable GUI frontend to tune them
like the parents want it. If it's nice and compatible, people will even pay
for it I guess.
Kind regards
Jan |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Sat Nov 28, 2009 9:14 pm
|
|