[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[xouweb] expert needed: arch doesn't support multi-committer archives!
From: |
Jonathan Walther |
Subject: |
[xouweb] expert needed: arch doesn't support multi-committer archives! |
Date: |
Mon, 6 Oct 2003 00:46:08 -0700 |
User-agent: |
Mutt/1.5.4i |
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
- [xouweb] expert needed: arch doesn't support multi-committer archives!,
Jonathan Walther <=