Backup Central

Ryan Castle <ryan < at > solutionsfirst.com.au>
wrote the following on Thu, 26 Feb 2004 15:57:57 +1100

We're trying to get the web interface to restores of old versions of
directories, however we don't want the webserver to run as anything
privileged and we don't want to expose the backup repositories to
anything but the webserver. At the moment the webserver is added to
the "rbackup" group which is the primary group of all the
rdiff-backup. Restoring files seems to work fine, but when we
attempt to restore a directory rdiff-backup thinks the webserver
isn't a member of the directories' group, and fails when it tries to
chmod() the files to 770. I've added a function issecondarygroup()
to the rpath class. It currently uses the 'id' program to get all
the process' group ids. Total hack, but I couldn't find any python
docs that told me do it nicely. Then I 'or'ed that onto the
isgroup() return statement. Do you think this is likely to cause
problems?

Perhaps I misunderstand the idea of a group, but I thought that a
process can only be running under one group. Whenever a process tries
to, say, delete a file, whether that succeeds depends only on the
current uid and gid.

However, a user may be in several supplementary groups. This means
that processes running under certain uids can switch their gid at will
to the gids in this list.

So if the rdiff-backup process is in the wrong group, having it simply
believe that it is in the right group won't fix anything. Instead
you need to do something like "newgrp rlbackup" to get the process in
the right group.

Someone please correct this if it's wrong. I really haven't used
groups much---the above is just my intuitive understanding.


--
Ben Escoto

Ben Escoto <bescoto < at > stanford.edu>
wrote the following on Mon, 17 May 2004 18:37:16 -0700

Someone please correct this if it's wrong. I really haven't used
groups much---the above is just my intuitive understanding.

Oops, as Ryan suggested, this is all wrong. (The group stuff on my
laptop seems to be broken, so I didn't notice this.) I guess all the
groups are checked for permission. I just changed isgroup() in
rpath.py from

return self.conn.Globals.get('process_gid') == self.data['gid']

to

return self.data['gid'] in self.conn.Globals.get('process_groups')

Hopefully this fixes the problem.


--
Ben Escoto

On 17 May 2004, Ben Escoto <bescoto < at > stanford.edu> wrote:
Ben Escoto <bescoto < at > stanford.edu>
wrote the following on Mon, 17 May 2004 18:37:16 -0700

Someone please correct this if it's wrong. I really haven't used
groups much---the above is just my intuitive understanding.

Oops, as Ryan suggested, this is all wrong. (The group stuff on my
laptop seems to be broken, so I didn't notice this.) I guess all the
groups are checked for permission. I just changed isgroup() in
rpath.py from

return self.conn.Globals.get('process_gid') == self.data['gid']

to

return self.data['gid'] in self.conn.Globals.get('process_groups')

Hopefully this fixes the problem.

The process groups is a bit strange: a process has a primary group
and a set of supplementary groups. The primary group is not
necessarily in the list of supplementary groups, which is what I
suppose process_groups holds. So you need to check both.

But why don't you just use access() to see if you have access?

--
Martin