[xouweb] expert needed: arch doesn't support multi-committer archives!

[Jonathan Walther]

To get some experience with the Xouvert project, I created an archive
and repositories to put the project website under arch management.

This worked reasonably well as long as I was the only one using it.  But
when I tried to let other people commit to the repositories, the
permissions got mucked up.  I spent time on IRC with Tom Lord, Andrew
Suffield, and some other very helpful souls.  They said that this was a
problem for sysadmins to solve, or at least for a sysadmin to point out
what arch needs to do to enable a solution.

I will describe exactly what I did, the problems I ran into, and the
fixes I tried.  I really need a functioning multi-committer archive
soon.

And I am not the only one.  If Savannah and FreeDesktop.org are going to
support arch as a revision management system, we need a well documented
way to allow committers access to an archive without compromising
security in any way.  Preferably the permission mechanism will just be
to add a committers user-id to the projects group.

I can see several scenarios for an archive.

1) single user makes commits, project group members can do checkouts.
2) single user makes commits, everyone else can do checkouts.
3) project group does commits, noone else can do checkouts.
4) project group does commits, everyone else can do checkouts.
5) everyone can do commits, everyone can do checkouts.

I want scenario 4.

Each scenario involves different permissions for the directories and
files involved.  What are these directories and files?  Here is an
example, where /x is the archive, and /x/r is the specific repository:

drwxrws---    4 root     xouvert      4096 Sep 27 00:03 /x/
drwxrws---    4 djw      xouvert      4096 Sep 26 20:41 /x/r/
-rw-r--r--    1 djw      xouvert        52 Sep 26 20:40 /x/r/.archive-version
-r--r--r--    1 djw      xouvert        18 Sep 26 20:41 /x/r/.listing
drwxrws---    2 djw      xouvert      4096 Sep 26 20:40 /x/r/=meta-info/
-r--r--r--    1 djw      xouvert        18 Sep 26 20:40 /x/r/=meta-info/.listing
-rw-r--r--    1 djw      xouvert        13 Sep 26 20:40 
/x/r/=meta-info/http-blows
-rw-r--r--    1 djw      xouvert        23 Sep 26 20:40 /x/r/=meta-info/name
drwxrws---    3 djw      xouvert      4096 Sep 26 20:41 /x/r/h/
-r--r--r--    1 djw      xouvert        16 Sep 26 20:41 /x/r/h/.listing
drwxrws---    3 djw      xouvert      4096 Sep 26 20:41 /x/r/h/h--m/
-r--r--r--    1 djw      xouvert        21 Sep 26 20:41 /x/r/h/h--m/.listing
drwxrws---   13 djw      xouvert      4096 Oct  3 18:07 /x/r/h/h--m/h--m--1.0/
-r--r--r--    1 johann   xouvert        99 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/.listing
drwxrws---    2 djw      xouvert      4096 Sep 26 22:19 
/x/r/h/h--m/h--m--1.0/base-0/
-r--r--r--    1 djw      xouvert        62 Sep 26 20:46 
/x/r/h/h--m/h--m--1.0/base-0/.listing
-r--r--r--    1 djw      xouvert     58657 Sep 26 20:46 
/x/r/h/h--m/h--m--1.0/base-0/h--m--1.0--base-0.src.tar.gz
-r--r--r--    1 djw      xouvert       535 Sep 26 20:46 
/x/r/h/h--m/h--m--1.0/base-0/log
drwxrws---    2 djw      xouvert      4096 Sep 26 22:40 
/x/r/h/h--m/h--m--1.0/patch-1/
-r--r--r--    1 djw      xouvert        67 Sep 26 22:19 
/x/r/h/h--m/h--m--1.0/patch-1/.listing
-r--r--r--    1 djw      xouvert       993 Sep 26 22:19 
/x/r/h/h--m/h--m--1.0/patch-1/h--m--1.0--patch-1.patches.tar.gz
-r--r--r--    1 djw      xouvert       493 Sep 26 22:19 
/x/r/h/h--m/h--m--1.0/patch-1/log
drwxrws---    3 djw      xouvert      4096 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/patch-2/
drwxrwsrwx    3 johann   xouvert      4096 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/patch-2/++revision-lock/
drwxrwsrwx    2 johann   xouvert      4096 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/patch-2/++revision-lock/+contents/
-r--r--r--    1 johann   xouvert        68 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/patch-2/.listing
-r--r--r--    1 johann   xouvert      2520 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/patch-2/h--m--1.0--patch-2.patches.tar.gz
-r--r--r--    1 johann   xouvert       571 Oct  3 18:07 
/x/r/h/h--m/h--m--1.0/patch-2/log

You can see what I attempted.  I tried to give all directories the
permissions 2770, so that any subdirectories would get created with the
same group ownership as the parent.  The 77 allowed the owner and all
xouvert group members to create files in the directories, as well as
chdir to them and list them.

For every new patch, a new directory is created.  This is where the
problems start.  The permissions of the new directories aren't the same
as the permissions on the parent.  I ended up with a ++revision-lock
that locked out all the other commiters, because it's permissions looked
like this:

drwxr-xr-x djw xouvert ++revision-lock/

This archive is only accessible with the sftp method.

For normal secure usage, users have a umask of 0022.  This is a great
default.  Except when it comes to using arch with sftp.

For the other xouvert committers, I set their umasks to 0, so they could
commit without preventing others from committing.

But I, as a regular user on my system, am loathe to change my umask from
it's comfortable 0022.

And setting the other users umasks to 0 wasn't ideal either.  As you can
see, now the permissions on the ++revision-lock as created by arch is
way too permissive.

drwxrwsrwx johann xouvert ++revision-lock/

My original scheme of giving all directories permissions of 2770 and
adding all committers to the xouvert group is now sort of working.

Can anyone tell me how to do this securely?

Can anyone recommend a change to arch that will let it conform to your
security policy by default?

For instance, I would like the following policy for files and
directories:

drwxrwsr-x user group dir/
-r--r--r-- user group file

The reason I don't specify -rw-rw-r-- is that all the files I can see in
the repository are not intended to be modified, EVER.

Remember the original 4 scenarios I specified?  Here are the policies
that would work out well for them:

1) single user makes commits, project group members can do checkouts.
drwxr-s--- user group dir/
-r--r----- user group file

2) single user makes commits, everyone else can do checkouts.
drwxr-sr-x user group dir/
-r--r--r-- user group file

3) project group does commits, noone else can do checkouts.
drwxrws--- user group dir/
-r--r----- user group file

4) project group does commits, everyone else can do checkouts.
drwxrwsr-- user group dir/
-r--r--r-- user group file

5) everyone can do commits, everyone can do checkouts.
drwxrwsrwx user group dir/
-r--r--r-- user group file

6) singer user makes commits, noone else can do checkouts.
drwx--s--- user group dir/
-r-------- user group file

sftp DOES have a umask command built in, so arch can set the permissions
to whatever the sftp user-login has the ability to.

So how can we tell arch about these policies?

How can I make my setup secure without going through contortions?
I will not change my regular umask, but I am ok with arch changing the
umask from inside the sftp session, for the duration of the session.

Xouvert needs to allow group members to make commits to an archive
without giving the whole world enough access to ruin the
++revision-lock.

Please help!

Jonathan

--

   It's not true unless it makes you laugh,                           
            but you don't understand it until it makes you weep.      

   -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                    Geek House Productions, Ltd.

 Providing Unix & Internet Contracting and Consulting,
 QA Testing, Technical Documentation, Systems Design & Implementation,
 General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   address@hidden
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

signature.asc
Description: Digital signature