GNOME.org
 

Re: gdm && gnopernicus


George:

Sorry about the late response to this email you sent on August 22nd,
but my comments are buried below and highlighted with "###"...


On Wed, Aug 20, 2003 at 07:41:56PM +0300, Adi Dascal wrote:


Hi all,

I am new to this list so I will start with the description of the
project I am working on and later on I will continue with the issues
that I have.

Project description:
Gnopernicus is an open source screen reader/magnifier that enables users
with limited vision, or no vision, to use the GNOME 2 desktop and GNOME
applications effectively. By providing automated focus tracking and full
screen magnification, Gnopernicus aids low-vision GNOME users, and its
screen reader features will allow low-vision and blind users to access a
large range of applications via speech and braille output.

About gnopernicus design:
Gnopernicus is basically made of two processes: gnopernicus, which is
the GUI and configures all kind of settings (through UI) and launches
the srcore process, which is executing all features.
Srcore can work by itself (alone), its settings being made by commands
mapped on different keys. Srcore is using gconf too.


What is to be implemented:
It is necessary for gnopernicus to work at login time, gnopernicus or
only srcore being launched by a gesture (for instance CTRL+k), so blind
or visually impaired people can use gdm.

Problems that I am aware of for this "conjunction":
Gnopernicus needs to be configurable by each type of user as some of
them might be blind and deaf (they need to configure the braille device
so gnopernicus will interact with them only through braille), some of
them might be visually impaired and only see if the "invert" feature
(the magnified region to be inverted in terms of color) is turned on,
other might see only with a very large zoom factor etc.
All these settings have to be made at login time so different kind of
people can use gdm with gnopernicus.

The first solution that was proposed was to make command line options
for gnopernicus/srcore. Having a LOT of features, there is a LOT to
configure in gnopernicus/srcore, so the number of command line options
would be VERY HIGH.
So this solution is not valid.

Another solution that I proposed was to use configuration files like
gdm's.
I discovered the libvicious library, that is used by gdm, and I was
wondering if this is OR is not the solution for us : having *.conf files
that would configure srcore as gdm.conf configures gdm.(probably we
should pass the *.conf file as parameter so more than one configuration
will be available for the user, files that could be stored on SunRay's
cards etc)
If this library offers something similar to gconf we would have 2
parallel solutions for dealing configuration (one for login time -
libvicious and second for "regular" run - gconf).
I am not so familiar with this library ( I saw its ve_config_set_* and
ve_config_get_* functions in the test-ve-config program - they seem much
alike gconf), but seems to be a pretty good choice.
One of the things that I noticed by digging a little deeper was that it
does not support setting float numbers and lists, but this would be easy
to add to the library as I saw. Another thing that I have noticed is
that you have to know each key's type and always use the function for
its type (gconf stores the type in its xml and it is a very useful
thing), but this could be implemented in libvicious too.
A thing that I am interested in, but haven't noticed yet (maybe there is
support but I haven't seen it) is a notification mechanism.
It would be useful if somebody might inform us about other implications
of this solution.

The last idea that I had is to use gconf at login time, too.
Actually this was the first idea, but there were some issues related to
the fact that gdm is a user that has no home.
After a little more research I found out that it is possible to use
gconf at login time and as a matter of fact I succeded in using
gnopernicus with gdm on a Linux system. (I did not try it on Solaris
yet). Note: I launched it pressing CTRL+k (please see the attachement of
the configuration file) and I used it turning on and off services and
configuring stuff through its UI.
The solution that I found is based on gconf's ability to use certain
configuration sources:
<snip from docs of gconf>
Users can specify configuration sources  which will be used by the
gconfd per-user configuration server. gconfd loads the file
/etc/gconf/2/path (or ${sysconfdir}/gconf/${version}/path) on startup;
this file contains a list of configuration source addresses. A source
address is similar to a URL; it contains a "protocol" name (in this
case, the name of the backend to use), followed by a colon, standard
flags separated by commands, another colon, and then backend-specific
information. For example, the address  xml:readonly:/home/hp/.gconf.xml
refers to an XML backend file tree rooted at /home/hp/.gconf.xml that
should be "mounted readonly" so that no data is written to it.

/etc/gconf/2/path stores a list of addresses, which form a configuration
source path. When looking up a value, GConf will begin with the first
source in the path, and continue checking each source until the value is
found or there are no more sources. When setting a value, GConf will use
the first writable source. Administrators can impose mandatory settings
on their users by placing only read-only configuration sources in the
path, or by placing a read-only source at the front of the path and
setting specific values in that source. Administrators can provide
default values by placing a systemwide source at the end of the
configuration source path.

The source configuration file can contain "include" statements and some
magic variables; you can use this to include a .gconf.path file from the
user's home directory. Variables are placed in $(). Two variables are
built-in to GConf: $(HOME) is the user's home directory, and $(USER) is
the username. You can also access any environment variable by prepending
ENV_ to the variable name. For example, $(ENV_FOO) will be replaced by
the FOO environment variable.
</snip from docs of gconf>
As gdm has the "home" directory /var/gdm, gnopernicus' gconf files are
saved there on Linux system. (I would expect to have the same behaviour
on Solaris even if there is no user gdm on it, the system administrator
would have to create it for gdm. Right?)
There could be other solutions, telling through the 'path' file to use
gconf-files from /opt/gnome-2.4/var/gdm/gnopenricus (for example), so
basicaly the key to the problem is how access rights are given to
certain configuration folders/files and how 'path' is setting the
configuration sources.

This seem to be the BEST and easiest solution, but I am not sure about
the security issues that might appear. Could you tell me if there could be this kind of implications? 

Thank you && Best regards,
Adi Dascal
BAUM Engineering, Romania



OK, so let me explain a bit about the config stuff.  The gdm user is not
required to actually have a home directory, though /var/gdm (the ServAuthDir)
is usually set.  GDM daemon doesn't actually run as the 'gdm' user, that's
only the GUIs.  The GDM daemon is trying to minimize the amount of code
and simplicity of configuration.  The GUI setup tool for GDM doesn't allow
you to change all the options and so the more esoteric configurations must be
made by editting the config file.  The config file is made for simplicity,
it is a standard INI based file that is easily human readable and even
simply parsable from scripts (see for example the gdm-stop script).  There
is no notification built in to the ve_config_ API for reasons of simplicity,
they work directly on some file, trying to preserve the structure of that
file and trying to be "compatible" with human edits (such as preserving
comments and trying to put new keys in the right places and all that).
It is a very simple API.  Notification is done in the GDM daemon through
the GDM control protocol, and it is only done for some keys as the GDM daemon
does not cope with changing all keys without restart.  I really do not
wish to run GConf or anything too complex as root that also adds a corba
communication socket and such things to the mix as that is just adding a
lot of code and complexity to a possibly dangerous place.  Plus obviously
gconf is hard to edit "by hand" and that is a "requirement" for gdm.
Perhaps this will change in the future, but for now I'd really like to
keep the gdm daemon configuration simple.  Though of course this doesn't
mean anything about what gnopernicus should use as gnopernicus/srcore
should not ever run as root.


Note that programs like gok and gnopernicus use gconf to control various
look and feel preferences.  It would be rather nasty if these programs
had to implement a separate prefernece management system for login use.
It would obviously be ideal if they could continue using the existing
gconf infrastructure.

Also note that any programs launched via gesture listeners will be
running as the "gdm" user and not as root, so I am not sure that the
dangers of adding the corba communication socket, etc. are such a problem.
Also, just because gconf is a dependancy of running gok or gnopernicus
does not mean that gconf becomes a dependancy of gdm2.  You can launch
any programs you want via the gesture listeners.  If you choose to
launch programs that depend on gconf, then that is a choice the system
administrator can make.

We do not intend to allow the user to configure gok or gnopernicus
at login time.  Instead these appliations will launch with the preference
windows disabled.  Instead, different gestures can be used to launch
gok or gnopernicus with the correct preset preference choices.  In
other words, we intend to specify specific manditory gconf settings
for both gok and gnopernicus.  These can only be overridden by
passing command-line arguments when launching gok or gnopernicus.
Different gestures will pass in different arguments, allowing gok
or gnopernicus to be launched in different ways.

In other words, I do not think it is necessary to save gconf values
at all in the gdm home directory, nor necessary to have a gdm home
directory at all.

Also, the system administrator can use gconftool to change the
manditory settings "by hand" if necessary.


Also gdm configuration can only be done by root and thus there is no need
for mandatory settings as they are all in fact mandatory in a way.

Here also lies one thing about running a tool from gdm screen, if you allow
it to be configured freely, then a malicious person could "misconfigure"
it without even having to log in, and then the actual user, having some
disability, may have a hard time changing the config back.  Perhaps the
config tool (gnopernicus I suppose) could be launched from the gdmsetup
tool.  This way it is protected behind a root password so that only
root could change the settings.  A user could only launch srcore through
the guesture.


As mentioned above, the intention is that at login time, all AT programs
would be launched without preference screens.  Users will not be able to
change any preferences.


I would really like to make setting up gdm to be accessible easy from the
gdmsetup GUI, I think there really should be no messing with script files and
hand editting config files and such.  Obviously such changes can only go in
after the 2.4 freeze is over though, but I'd consider this a very important
feature.  I'm not too familiar with the current accessibility stuff though
unfortunately.  Is it only that the right modules need to be inserted into
the greeter?  And then the standard config for the guesture modules would
launch gnopernicus and/or srcore?


Gesture listeners are loaded into the greeter/chooser programs when they
startup.  These gesture listeners listen for particular gestures that can
be configured via the /etc/gdm/modules/AccessDwellMouseEvents and
/etc/gdm/modules/AccessKeyMouseEvents files.

Once a gesture is recognized, then a shell command is executed via
g_spawn_async().  This command can specify options to gok or gnopernicus
to launch with specific preferences.  Therefore multiple gestures can
be used to launch gok with different preference settings, etc.


Obviously this means that there is only one configuration per system, and
this is not that simple to solve since this is run before the user enters
the login name, so before we know who it is.  I suppose the sysadmin could
setup different profiles and then different guestures for each profile,
so that if you had two people with different disabilities, they would use a different guesture to launch srcore with their correct 
configuration.  This could be the only command line needed to be added
to srcore, that is "--profile=foo".


Hopefully you better understand how multiple gestures can be used to
specify different preferences.  It is necessary to work this way because
some users may not be able to navigate a preference dialog.  For example,
imagine a person using special hardware.  A gesture listener is written to
listen to specific hardware events and launch various AT programs when
the events are received.  This user cannot control the mouse, so they
could not navigate the preference screen anyway.  The AT program has to
come up with the correct configuration upon receiving the initial gesture.
This is why multiple gestures are likely necessary for the same
application, to assist people with different disabilities.


It would be of course nice then to have some gui to edit the config file for
the guestures and to be able to create different profiles in gnopernicus.
Both of these can be launched from the gdmsetup tool.  (gdmsetup must run
as root, but we could launch gnopernicus and whatever else as the gdm user
with no problems).


Yes, there is no reason why the AccessDwellMouseEvents and AccessKeyMouseEvents
couldn't be managed via the gdmsetup tool.  There is no need to create
different profiles in gnopernicus.  The mandatory gconf settings are only used
to define the default gnopernicus behavior and command line argument would be
used to allow certain gestures to override this behavior for specific
accessible needs.

Hope this makes things more clear.

Basically we want to make sure that our plans to launch programs that require
gconf from gdm using the gesture listeners makes sense and doesn't open any
ugly security issues.

Thanks!

--

Brian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]