Multi-user gnucash

[ghaverla@freenet.edmonton.ab.ca]

On Fri, 23 Mar 2001, Rich Shepard wrote:
> On Fri, 23 Mar 2001 ghaverla@freenet.edmonton.ab.ca wrote:
> 
> > I am guessing that the data files are in in the home directory
> > of some user (for arguments purposes, rich).  So, you'll have
> > files like:
> 
>   They're in /home/pers-data/ which is owned by root and the group is users.
> Both my wife and I are in the group users so we both have read-write access
> to these files.
> 
> > Is your wife logging in via telnet as rich, or is she logging
> > in as "wife", and is relying on directory/file permissions
> > to allow her to read/write the various files in your (/home/rich)
> > directory?
> 
>   She logs in under her username and the /home/pers-data/ directory has
> permissions 775 (except the group "execute" is 's' rather than 'x'). Same
> setup for /home/shared-data/ where commonly-accessed business data reside.

That s is indicating something called SGID (Set Group ID).  What
it does is force the group of any file created under /home/pers-data/
to be in group "users" (which is the group of /home/pers-data).

> > GnuCash isn't trapping all (enough of) the signals?

[ My talking about signals was sort of like talking out
  loud to myself (and other people who program in C). ]

>   The window manager is xfwm. We run Xfce here as the desktop/task switcher.

I haven't run either of those.  There sure are a lot
of window managers around.

> > But sometimes, we assume that we only wear two hats, when we probably
> > should be wearing more than 2.  In this case, it might actually help
> > things a bit if your machine had a pfinance ID, and when either of you had
> > "personal" (probably actually finances of you as a couple) finance work to
> > do, both of you would log in as pfinance to do this work, and not do it as
> > "rich" or "wife".
> 
>   Why? Isn't that why users can belong to multiple groups? Groups can permit
> certain users to access data in directories that are not accessible to those
> users who are not members of that group. As I understand system
> administration, that's the function of groups and there's no need to have
> multi-user usernames for folks.

Philosophy?  I believe the limit depends on the exact flavour of
UNIX/Linux, but I think a user can only belong to a certain small
number of groups (16 rings a bell).  There are allowed to be many
more groups than this on a machine.

One reason is "damage containment".  If you have a UID for persdata,
and you log into that ID when you want to work with that data,
then if something happens (like accidentally deleting files)
you can only damage that group of files.  Likewise, if you are
logged in as rich, and accidentally delete files, the files of
the user "persdata" would most like not be effected.

Another is sort of applicable in a consulting context, and that
is accounting.  If a person starts a new UID for every project
(they might very likely all have the same password), then it
is quite easy to track how much time/resources you use on every
project.  Of course, you have to remember to log out when
you aren't "at the computer".

But you are certainly allowed to belong to multiple groups
and just log in as a single person.

> > Does this solve the problem of leaving behind LCK/LNK files if the program
> > exits "improperly" over a network connection?
> 
>   I guess I don't understand why gnucash would exit improperly from a telnet
> session.

If you use the "exit" function from the file menu, or from
the buttons on the gnucash window, I don't think it can.
The people at gnumatic would know better than me.  But, if
the connection dies (on a dialup connection, this can happen
quite easily), somehow the gnucash program has to die as it
no longer has a controlling terminal/program.  Sometimes your
login shell takes care of this.  Linas mentioned some protocol
by which the window manager would kill gnucash if you killed
the window gnucash was running in.

In the language of C, a signal is being sent.  If you've used
the 'kill' program on the command line, you know that sometimes
kill PID doesn't work?  The default signal sent is INTERUPT
(also called SIGINT).  So then a person might try something like
kill -9 PID, where 9 is the untrappable KILL signal (SIGKILL).
Or maybe you want a copy of the running image on the disk, in
which case you could send a signal to cause a "core dump".

Gord

Matter Realisations     http://www.materialisations.com/
Gordon Haverland, B.Sc. M.Eng. President
101  9504 182 St. NW    Edmonton, AB, CA  T5T 3A7
780/481-8019            ghaverla @ freenet.edmonton.ab.ca
780/993-1274 (cell)