Re: external merge tool argument order does not match sample in svn-book

[Stefan Sperling]

On Wed, Jul 20, 2011 at 02:41:02PM -0600, Steven Trabert wrote:
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externaldifftools.merge,
> Example 7.6 "mergewrap.py" shows the argument order as
> ># Get the paths provided by Subversion.
> >BASE   = sys.argv[1]
> >MINE   = sys.argv[2]
> >THEIRS = sys.argv[3]
> >MERGED = sys.argv[4]
> >WCPATH = sys.argv[5]
> Example 7.7. mergewrap.bat shows the same order as Example 7.6.
> 
> However, the routine svn_cl__merge_file_externally in svn/util.c,
> 1.6.17,  uses a different order ( the mine and their arguments are
> switched ):
> 
> >arguments[0] = merge_tool;
> >arguments[1] = base_path;
> >arguments[2] = their_path;
> >arguments[3] = my_path;
> >arguments[4] = merged_path;
> >arguments[5] = wc_path;
> >arguments[6] = NULL;
> 
> the current version, r1140729, shows the same order in util.c as 1.6.17.
> 
> ** 

Can you file a ticket in the book's issue tracker, please?
http://code.google.com/p/svnbook/issues/list
Thank you!

Server sent unexpected return value (504 ) in response to MERGE request for '/xxx'

[zhiwei chen]

Hi,all!

When I commit some file(263 directories, 3016 files, and 30M), I encountered
with this error:
svn: Commit failed (details follow):
svn: Server sent unexpected return value (504 ) in response to MERGE request
for '/xxx'

message bellow are apache error logs:
[Thu Jul 20 16:45:20 2011] [error] [client 10.3.2.1] Could not MERGE
resource "*/xxx/*!svn/act/8a08e062-8a1a-455e-b839-467adb4ae971" into
"/xxx".  [409, #0]
[Thu Jul 20 16:45:20 2011] [error] [client 10.3.2.1] An error occurred while
committing the transaction.  [409, #2]
[Thu Jul 20 16:45:20 2011] [error] [client 10.3.2.1] Can't open file
'/data0/repository/xxx/db/transactions/0-1.txn/props': No such file or
directory  [409, #2]

My environmen is:

CentOS5.6 x86_64

stunnel handle https request

stunnel send request(http) to haproxy

haproxy send requests to apache
(haproxy's contime=4000,srvtime=50,clitime=50)

apache use mod_dav_svn.so to operate svn repository

I want to know, if MERGE really waste time? How to resolve this error?

thank you!

Re: Subversion: existing users

[Andy Canfield]

ADDENDUM ...

I used root to create the /data/svn directory. Then, anticpiating 
problems, I did a chmod to make it writable to all.


Later I ran svnadmin create /data/svn/sample and it created an entire 
repository directory tree under /data/svn. I don't remember but I 
probably ran it as root.


I just now noticed that /data/svn/sample and all the sub-directories and 
files therein are owned by root and, usually, writable only by root. 
This is probably going to cause problems for Apache / mod_dav_svn which, 
of course, runs as the 'apache user' ("www-data") instead of root.


Where did I go wrong? The manual talks about commands but does not seem 
to talk about what user is executing the command. Do I have to run 
svnadmin as www-data? Is there a way to create a repository using my 
browser?

Re: Subversion: existing users

[Andy Levy]

On Thu, Jul 21, 2011 at 06:12, Andy Canfield  wrote:
> ADDENDUM ...
>
> I used root to create the /data/svn directory. Then, anticpiating problems,
> I did a chmod to make it writable to all.

Giving global write permission will lead to problems as well.
Different problems, but problems nonetheless.

> Later I ran svnadmin create /data/svn/sample and it created an entire
> repository directory tree under /data/svn. I don't remember but I probably
> ran it as root.
>
> I just now noticed that /data/svn/sample and all the sub-directories and
> files therein are owned by root and, usually, writable only by root. This is
> probably going to cause problems for Apache / mod_dav_svn which, of course,
> runs as the 'apache user' ("www-data") instead of root.
>
> Where did I go wrong? The manual talks about commands but does not seem to
> talk about what user is executing the command. Do I have to run svnadmin as
> www-data? Is there a way to create a repository using my browser?

Your repository directory (the one you created with svnadmin create)
should be owned by www-data (or whatever account your server process
executes under). It doesn't matter whether you run svnadmin create as
that user, or run it as another user and then change ownership.

Re: Subversion: existing users

[Andy Levy]

On Thu, Jul 21, 2011 at 00:36, Andy Canfield  wrote:

>>> Alternatively, the SVN protocol will go to the svnserve program.
>>> Below the mod_dav_syn layer and the svnserve layer and the repository
>>> local
>>> layer is the "Subversion Repository". Significantly, this is diagrammed
>>> as
>>> data, not code. So mod_dav_syn must contain the code to manipulate the
>>> repository, and svnserve must also contain the code to manipulate the
>>> repository, and the Client Library (because of Local access) must contain
>>> the code to manipulate the repository.
>>> Below the "Subversion Repository" component is either "Berkeley DB" or
>>> "FSFS". I have already decided to use "FSFS" since I can look at it as
>>> it's
>>> sitting on the disk and therefore it is more conceptually transparent.
>>
>> FSFS doesn't expose the files directly. It's still a database of
>> sorts, just not a BDB database. You still need a Subversion client to
>> access the files.
>
> But I don't need a Subversion client to see the files, to read the files,
> and therefore to learn how things are stored. I'm the kind of guy who has
> looked at the directory & file structure created by MySQL for it's
> databases. It becomes possible to see the low-level implementation in case
> that answers a question about the high-level interface. Hey, that's why I
> use Linux and not the Microsoft Black Box System.

You can see the files that FSFS uses to *store* the data in your
repository, but you cannot read the actual contents. IOW, you can put
README.TXT into the repository, but you cannot read the contents of it
by looking at the FSFS data in vi.

>> The concepts described in the book change much less frequently than
>> the code. A significant portion of the "nightly" book applies to older
>> versions - but of course there are changes to cover new/modified
>> functionality, and general edits&  reorganization. There was no final
>> version of the book for 1.6.
>
> I suggest that the "Nightly Build" version be relabelled "Current", and put
> first.

Except that it's not necessarily. There may be things in the "Nightly"
book which address a yet-to-be-released version of Subversion, and the
book isn't finalized - there's potentially a new version every day.

But discussion about how the book is managed is off topic for this
mailing list. The book has its own mailing list, issue tracker and
repository. See the "Feedback/Contributing" section on the front page,
http://svnbook.red-bean.com/

Re: Subversion access control / Linux users etc.

[Andy Canfield]

More user/command interaction -

The commands to create the Subversion Repository Parent directory were
*sudo bash
mkdir /data/svn
chmod a+w /data/svn*
This created this directory:
*drwxrwxrwx 4 root 4096 2011-07-21 17:36 /data/svn/*

I ran this command as user root:
*svnadmin create /data/svn/sample*
and what I get is
*drwxr-xr-x 6 root 4096 2011-07-21 11:08 /data/svn/sample/*

I ran this command as user andy:
*svnadmin create /data/svn/example*
and what I got is
*drwxr-xr-x 6 andy 4096 2011-07-21 17:36 /data/svn/example/*

It concerns me that apache is running as user 'www-data' and niether of 
these repositories are owned by, or even writable by, www-data. So I did 
these commands:

*sudo bash
su www-data
svnadmin create geronimo*
The output of the last command was as follows:
*svnadmin: Repository creation failed
svnadmin: Could not create top-level directory
svnadmin: Can't create directory 'geronimo': Permission denied*
That surprises me; the /data/svn directory is writable by everyone. Ah well.

The browser, when pointing to http://localhost/svn/RepoName, gives this 
answer

*RepoName - Revision 0: /
Powered by Subversion version 1.6.12 (r955767)*.
This is true whether RepoName is 'sample' or 'example'. Of course, the 
only thing mod_dav_svn needs to do in this case is to read the 
repository, and all files and directories are readable by everyone, 
regardless of whether they are owned by root or andy.


So the browser access mechanism has no commands to control a repository, 
only to describe it? Logically this might make sense; however I would 
expect that http://localhost/svn would be capable of listing the 
repositories and creating new repositories.. But when I point the 
browser to http://localhost/svn I get this response:

*Forbidden
You don't have permission to access /svn/ on this server.
Apache/2.2.17 (Ubuntu) Server at localhost Port 80*
When I look at /var/log/apache2/error.log I see these lines:
*[Thu Jul 21 17:54:04 2011] [error] [client 127.0.0.1]
Could not fetch resource information.  [403, #0]
[Thu Jul 21 17:54:04 2011] [error] [client 127.0.0.1]
(2)No such file or directory: The URI does not contain the name 
of a repository.

 [403, #190001]*
Ahah! So http://localhost/svn is NOT a valid Subversion URL. I was 
mistaken when I thought someone said that the Apache browser interface 
could give me a list of the repositories.


PROBLEMS WITH THE 'SVN' COMMAND -
As Linux user 'andy'. Here goes:
*rm -rf .subversion
svn info http://localhost/svn/sample --username='andy' 
--password=not-shown'*

*Password for 'default' GNOME keyring:
svn: OPTIONS of 'http://localhost/svn/sample': authorization failed:
Could not authenticate to server: rejected Basic challenge 
(http://localhost)
*The fact is that, as far as I know, I DON"T HAVE ANY %$#@! GNOME 
KEYRING! So when it asked for the Password for 'default' GNOME keyring I 
just pressed Enter. Then authenticiation failed.


OK, so I have completely removed the gnome-keyring package. I also had 
to wipe out the ~/.gnome2/keywrings directory. Now to try again.


Wait. Wait some more. Go down to 7/11; buy a hot dog and some potato 
chips. Come back home. It's been 20-30 minutes. Command still hasn't 
completed. Nothing in /var/log/apache2/error.log. Just a dead svn 
program. Had to kill -9.


When it comes to plants, some people have a green thumb; I have a brown 
thumb. Looks like when it comes to Subversion I have a black thumb.

Re: Subversion: existing users

[Andy Canfield]

On 07/21/2011 05:55 PM, Andy Levy wrote:

On Thu, Jul 21, 2011 at 06:12, Andy Canfield  wrote:

ADDENDUM ...

I used root to create the /data/svn directory. Then, anticpiating problems,
I did a chmod to make it writable to all.

Giving global write permission will lead to problems as well.
Different problems, but problems nonetheless.


Later I ran svnadmin create /data/svn/sample and it created an entire
repository directory tree under /data/svn. I don't remember but I probably
ran it as root.

I just now noticed that /data/svn/sample and all the sub-directories and
files therein are owned by root and, usually, writable only by root. This is
probably going to cause problems for Apache / mod_dav_svn which, of course,
runs as the 'apache user' ("www-data") instead of root.

Where did I go wrong? The manual talks about commands but does not seem to
talk about what user is executing the command. Do I have to run svnadmin as
www-data? Is there a way to create a repository using my browser?

Your repository directory (the one you created with svnadmin create)
should be owned by www-data (or whatever account your server process
executes under). It doesn't matter whether you run svnadmin create as
that user, or run it as another user and then change ownership.

OK, restart again. The new commands to create the RepositoryParent 
directory are:

*mkdir /data/svn
sudo chown www-data.www-data svn*
This results in
*drwxr-xr-x 3 www-data www-data 4096 2011-07-21 19:01 /data/svn*
Here is the command I used to create a repository:
*sudo -u www-data svnadmin create /data/svn/sample3*
Now we have
*drwxr-xr-x 6 www-data www-data 4096 2011-07-21 19:01 /data/svn/sample3
-rw-r--r-- 1 www-data www-data  229 2011-07-21 19:01 
/data/svn/sample3/README.txt*

etc.

When I point my browser to http://localhost/svn/sample3 I still get this 
short page:

*sample3 - Revision 0: /
Powered by Subversion version 1.6.12 (r955767).*
so I still suspect that the browser interface is incapable of performing 
any action, including creating a repository, and is also incapable of 
giving me a list of repositories.

Re: Subversion: existing users

[Andy Levy]

On Thu, Jul 21, 2011 at 08:18, Andy Canfield  wrote:
>
>
> On 07/21/2011 05:55 PM, Andy Levy wrote:
>
> On Thu, Jul 21, 2011 at 06:12, Andy Canfield 
> wrote:
>
> ADDENDUM ...
>
> I used root to create the /data/svn directory. Then, anticpiating problems,
> I did a chmod to make it writable to all.
>
> Giving global write permission will lead to problems as well.
> Different problems, but problems nonetheless.
>
> Later I ran svnadmin create /data/svn/sample and it created an entire
> repository directory tree under /data/svn. I don't remember but I probably
> ran it as root.
>
> I just now noticed that /data/svn/sample and all the sub-directories and
> files therein are owned by root and, usually, writable only by root. This is
> probably going to cause problems for Apache / mod_dav_svn which, of course,
> runs as the 'apache user' ("www-data") instead of root.
>
> Where did I go wrong? The manual talks about commands but does not seem to
> talk about what user is executing the command. Do I have to run svnadmin as
> www-data? Is there a way to create a repository using my browser?
>
> Your repository directory (the one you created with svnadmin create)
> should be owned by www-data (or whatever account your server process
> executes under). It doesn't matter whether you run svnadmin create as
> that user, or run it as another user and then change ownership.
>
> OK, restart again. The new commands to create the RepositoryParent directory
> are:
>     mkdir /data/svn
>     sudo chown www-data.www-data svn
> This results in
>     drwxr-xr-x 3 www-data www-data 4096 2011-07-21 19:01 /data/svn
> Here is the command I used to create a repository:
>     sudo -u www-data svnadmin create /data/svn/sample3
> Now we have
>     drwxr-xr-x 6 www-data www-data 4096 2011-07-21 19:01 /data/svn/sample3
>     -rw-r--r-- 1 www-data www-data  229 2011-07-21 19:01
> /data/svn/sample3/README.txt
> etc.
>
> When I point my browser to http://localhost/svn/sample3 I still get this
> short page:
>     sample3 - Revision 0: /
>     Powered by Subversion version 1.6.12 (r955767).
> so I still suspect that the browser interface is incapable of performing any
> action, including creating a repository, and is also incapable of giving me
> a list of repositories.

The browser interface is only for looking at the repository. You
cannot administer repositories in any way using the built-in browser
interface. Nor can you check out, lock files, or commit via a web
browser. This is explained in the book.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.browsing

RE: Subversion: existing users

[Cooke, Mark]

> -Original Message-
> From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] 
> Sent: 21 July 2011 13:19
> To: nka...@gmail.com
> Cc: users@subversion.apache.org
> Subject: Re: Subversion: existing users
> 
> 
> 
> On 07/21/2011 05:55 PM, Andy Levy wrote: 
> 
>   On Thu, Jul 21, 2011 at 06:12, Andy Canfield 
>    wrote:
> 
>   ADDENDUM ...
>   
>   I used root to create the /data/svn directory. 
> Then, anticpiating problems,
>   I did a chmod to make it writable to all.
> 
>   
>   Giving global write permission will lead to problems as well.
>   Different problems, but problems nonetheless.
>   
> 
>   Later I ran svnadmin create /data/svn/sample 
> and it created an entire
>   repository directory tree under /data/svn. I 
> don't remember but I probably
>   ran it as root.
>   
>   I just now noticed that /data/svn/sample and 
> all the sub-directories and
>   files therein are owned by root and, usually, 
> writable only by root. This is
>   probably going to cause problems for Apache / 
> mod_dav_svn which, of course,
>   runs as the 'apache user' ("www-data") instead of root.
>   
>   Where did I go wrong? The manual talks about 
> commands but does not seem to
>   talk about what user is executing the command. 
> Do I have to run svnadmin as
>   www-data? Is there a way to create a repository 
> using my browser?
> 
>   
>   Your repository directory (the one you created with 
> svnadmin create)
>   should be owned by www-data (or whatever account your 
> server process
>   executes under). It doesn't matter whether you run 
> svnadmin create as
>   that user, or run it as another user and then change ownership.
>   
> 
> OK, restart again. The new commands to create the 
> RepositoryParent directory are:
> mkdir /data/svn
> sudo chown www-data.www-data svn

I don't use *nix much but shouldn't that be `chown -R ...`?

> This results in
> drwxr-xr-x 3 www-data www-data 4096 2011-07-21 19:01 /data/svn
> Here is the command I used to create a repository:
> sudo -u www-data svnadmin create /data/svn/sample3
> Now we have
> drwxr-xr-x 6 www-data www-data 4096 2011-07-21 19:01 
> /data/svn/sample3
> -rw-r--r-- 1 www-data www-data  229 2011-07-21 19:01 
> /data/svn/sample3/README.txt
> etc.
> 
> When I point my browser to http://localhost/svn/sample3 I 
> still get this short page:
> sample3 - Revision 0: /
> Powered by Subversion version 1.6.12 (r955767).
> so I still suspect that the browser interface is incapable of 
> performing any action, including creating a repository, and 
> is also incapable of giving me a list of repositories.

It WILL give you a list of reporsitories _under_a_parent_root_ IF you
configure it correctly.  Of course this tends to be easier (and less
secure?) under windoze...  As has been mentioned in other posts, you
need to give mod_dav_svn TWO directives:
SVNParentPath D:/svn/
SVNListParentPath On

What are you expecting the browser interface to give you?  It provides a
fairly simple, read-only interface to the repositories it is configured
to serve.  There are tools (ViewVC etc) that provide more functionality
but general operation is NOT through the browser but a subversion client
that happens to use https (etc) as the communication patheway.  (I
notice Andy Levy has addressed this point better than I)

~ mark c

Re: Subversion: existing users

[Nico Kadel-Garcia]

On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfield  wrote:
> ADDENDUM ...
>
> I used root to create the /data/svn directory. Then, anticpiating problems,
> I did a chmod to make it writable to all.
>
> Later I ran svnadmin create /data/svn/sample and it created an entire
> repository directory tree under /data/svn. I don't remember but I probably
> ran it as root.
>
> I just now noticed that /data/svn/sample and all the sub-directories and
> files therein are owned by root and, usually, writable only by root. This is
> probably going to cause problems for Apache / mod_dav_svn which, of course,
> runs as the 'apache user' ("www-data") instead of root.
>
> Where did I go wrong? The manual talks about commands but does not seem to
> talk about what user is executing the command. Do I have to run svnadmin as
> www-data? Is there a way to create a repository using my browser?

Welcome to sys-admin hell, the "documentation is true, but not
complete" world that I've spent so many years in. The connections
between different pieces of information that are obvious to someone
who's been through similar issues in the past are not obvious to a an
intelligent but new person like yourself.

It goes back to "what are you trying to achieve". If you're setting up
an svn+ssh repository with direct user logins, various components need
to be owned with "write" permissions for those users. This is
typically done by putting users in a particular authorized group, such
as "project1" for the "project1" repository at /var/svn/project1. The
configuration files, such as /var/svn/project1/conf/ and
/var/svn/project1/scripts, can be owned by any user or group, as long
as the connecting user has appropriate read or execute access.

If you're setting it up for web access, it needs to have the writable
/var/svn/project1/db directory writable by whatever user runs the HTTP
daemon, typically "apache" or "www-data" on modern Linux systems. If
you're setting up both web access  and svn+ssh, your life becomes more
interesting and we could review that. It's tricky to do well.

/var/svn/project1/db directory needs write access for the users. All
of them. When you use the kind of shared permission access you've
selected based on active local logins, you've given up control of that
directory to all the local users. It is theoretically possible to set
up cron job that scans that directory and resets ownership to a local
"svn" user of all successfully loaded revisions, and set the directory
permissions to 1777 to prevent users deleting each other's revisions,
but without such chicanery you cannot defend this file in that kind of
"shard access" setup.

This is also where you get into trouble with your ideal of "locking
down individual files". Individual working copy files aren't stored in
the database, they are *assembled* from the list of revisions involved
in modifying that file throughout that file's history. This is partly
why the most viable Subversion models of preventing individual file or
difectory modifications are all in the pre-commit stages, not in the
database structure itself.

And unfortunately, this sort of chicanery is not replicated for
backups: if you run "svnadmin hotcopy" to copy your repository, it
will not preserve the funky ownerships, and you'll need to deal with
it again.

Andy, it really sounds like you're getting caught up in the small
details. What *must* you have? Access for everyone with a valid system
login, or a designated list of users? Can your people use SSH keys,
which can seriously simplify ownership issues, and will HTTPS access
serve their needs?

empty pre-commit hook fails with svn+ssh with some accounts

[Daniel Neuberger]

We have a rather unique setup to meet certain requirements and as a
result I can't get any hooks to work (even empty ones or ones that
just exit with a zero return code).

In short, we have a repository owned by one user that is accessed by
tunneling over ssh to other user accounts.  To get around the
permission issues, the setuid bit is set on /usr/bin/svnserve for the
user that owns the repository.  Everything works fine except hooks
regardless of what permissions I give them or what the script does.
The hooks work fine though if I ssh to the user account that owns the
repository rather than another user account (we can't operate that way
though).

Everything else from the other user accounts works fine.  Also,
running the pre-commit hook from the other user accounts using an
empty environment works fine too.

All the scripts are bash scripts.  All systems are RHEL 5.5 using svn 1.4.

Any ideas?  Thanks.

- Daniel

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Nico Kadel-Garcia]

On Thu, Jul 21, 2011 at 9:36 AM, Daniel Neuberger
 wrote:
> We have a rather unique setup to meet certain requirements and as a
> result I can't get any hooks to work (even empty ones or ones that
> just exit with a zero return code).
>
> In short, we have a repository owned by one user that is accessed by
> tunneling over ssh to other user accounts.  To get around the
> permission issues, the setuid bit is set on /usr/bin/svnserve for the
> user that owns the repository.  Everything works fine except hooks
> regardless of what permissions I give them or what the script does.
> The hooks work fine though if I ssh to the user account that owns the
> repository rather than another user account (we can't operate that way
> though).
>
> Everything else from the other user accounts works fine.  Also,
> running the pre-commit hook from the other user accounts using an
> empty environment works fine too.
>
> All the scripts are bash scripts.  All systems are RHEL 5.5 using svn 1.4.

Stop *RIGHT* there. Go grab the Subverson 1.6.x from the RHEL updates.
Do not pass go, do not collect $200 until you do this sitewide.  There
are significant security and performance improvements, well worth the
update pain.

That said, putting "suid" bits on svnserve is just begging for
confusing pain in a configuration that no one has been using. Can you
not use the svn+ssh shared account access, with SSH keys restricted to
svnserve tunnel access, as documented in the Subversion Red Book?

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Daniel Shahaf]

ls -ald $REPOS_DIR $REPOS_DIR/hooks/ $REPOS_DIR/hooks/pre-commit

Daniel Neuberger wrote on Thu, Jul 21, 2011 at 09:36:22 -0400:
> We have a rather unique setup to meet certain requirements and as a
> result I can't get any hooks to work (even empty ones or ones that
> just exit with a zero return code).
> 
> In short, we have a repository owned by one user that is accessed by
> tunneling over ssh to other user accounts.  To get around the
> permission issues, the setuid bit is set on /usr/bin/svnserve for the
> user that owns the repository.  Everything works fine except hooks
> regardless of what permissions I give them or what the script does.
> The hooks work fine though if I ssh to the user account that owns the
> repository rather than another user account (we can't operate that way
> though).
> 
> Everything else from the other user accounts works fine.  Also,
> running the pre-commit hook from the other user accounts using an
> empty environment works fine too.
> 
> All the scripts are bash scripts.  All systems are RHEL 5.5 using svn 1.4.
> 
> Any ideas?  Thanks.
> 
> - Daniel

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Daniel Neuberger]

On Thu, Jul 21, 2011 at 10:51 AM, Nico Kadel-Garcia  wrote:
> Stop *RIGHT* there. Go grab the Subverson 1.6.x from the RHEL updates.
> Do not pass go, do not collect $200 until you do this sitewide.  There
> are significant security and performance improvements, well worth the
> update pain.
Okay, we plan to do that asap, but it will take at least a little
time.  In the meantime, there's no reason to believe that's causing my
problem though, right?

> That said, putting "suid" bits on svnserve is just begging for
> confusing pain in a configuration that no one has been using. Can you
> not use the svn+ssh shared account access, with SSH keys restricted to
> svnserve tunnel access, as documented in the Subversion Red Book?
That's what we're doing but the repository is owned by a separate user
as an additional security measure so that if someone somehow gains
shell access to the shared account, they won't be able to delete the
repository or anything like that.  Do you think there's anyway to make
it work this way?

Thanks for the help.

- Daniel

Re: Can I prevent a file from being modified?

[David Weintraub]

I have a pre-commit hook that allows you to set a directory as
"add-only". This was mainly for the tags directory. You can create a
tag, but once created, it can't be modified.

This should fit well in your process. You can give it a try. I've just
done a major rewrite that is more object oriented and allows you to
use LDAP groups for file permissioning. However, this link is to the
old tried and true version.



You'll need Perl on your Subversion repository server to run this, but
you shouldn't need any optional CPAN modules.

-- 
David Weintraub
qazw...@gmail.com

Re: Subversion access control

[Geoff Hoffman]

On Wed, Jul 20, 2011 at 9:14 PM, Andy Canfield wrote:

> **
> Thank you very much.
>
>
> On 07/20/2011 12:19 PM, Nico Kadel-Garcia wrote:
>
> On Tue, Jul 19, 2011 at 11:14 PM, Andy Canfield 
>  wrote:
>
>  One thing has hit my mind today that I don't think you realize ...
>
> I have never, in my entire life, seen a working Subversion system.
>
> Apparently Subversion, as distributed, doesn't work - the access
> authentications are deliberately turned off.
>
>  I'm afraid it depends on your access requirements. Seriously. Which
> access technology are you using? svn+ssh (which I tend to recommend),
> or Apache (using https://), or svn directorly (svn://) Start with that
> and we'll walk you through it.
>
>
> OK, here goes.
>
> I would like to use http/https. I am not supposed to be working on the
> server, but on my notebook workstation. And svn or svn+ssh require port 3690
> to be forwarded by the router, and we don't own the router. So I would
> prefer http and/or https.
>
> But on the actual server https is screwed up because mod_dev_svn.so is a
> year earlier than Apache, and apparently there is a version mismatch. When
> svn is enabled apache is dead. I have put in a request for my friend to
> re-install, but that could take a week.
>
> So for the interim I have installed mod_dav etc. on my notebook computer.
> FYI it is running Ubuntu Linux 1.04. This is for testing.
>
> Directory /etc/apache2/modes-enabled contains the file dav.load with this
> contents:
> *LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so*
> That same directoy also contains the file dav_syn.load with these contents:
> *# Depends: dav
> LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so
> LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so*
> That same directory also contains the file dav_svn.conf which I altered;
> this is the altered contents:
> *# dav_svn.conf - Example Subversion/Apache configuration
> #
> # For details and further options see the Apache user manual and
> # the Subversion book.
> #
> # NOTE: for a setup with multiple vhosts, you will want to do this
> # configuration in /etc/apache2/sites-available/*, not here.
>
> #  ... 
> # URL controls how the repository appears to the outside world.
> # In this example clients access the repository as http://hostname/svn/
> # Note, a literal /svn should NOT exist in your document root.
>
> 
>
>   # Uncomment this to enable the repository
>   DAV svn
>
>   # Set this to the path to your repository
>   #SVNPath /var/lib/svn
>
>   # Alternatively, use SVNParentPath if you have multiple repositories
> under
>   # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, ...).
>   # You need either SVNPath and SVNParentPath, but not both.
>   #SVNParentPath /var/lib/svn
>   SVNParentPath /data/svn
>
>
>   # Access control is done at 3 levels: (1) Apache authentication, via
>   # any of several methods.  A "Basic Auth" section is commented out
>   # below.  (2) Apache  and , also commented out
>   # below.  (3) mod_authz_svn is a svn-specific authorization module
>   # which offers fine-grained read/write access control for paths
>   # within a repository.  (The first two layers are coarse-grained; you
>   # can only enable/disable access to an entire repository.)  Note that
>   # mod_authz_svn is noticeably slower than the other two layers, so if
>   # you don't need the fine-grained control, don't configure it.
>
>   # Basic Authentication is repository-wide.  It is not secure unless
>   # you are using https.  See the 'htpasswd' command to create and
>   # manage the password file - and the documentation for the
>   # 'auth_basic' and 'authn_file' modules, which you will need for this
>   # (enable them with 'a2enmod').
>   #AuthType Basic
>   #AuthName "Subversion Repository"
>   #AuthUserFile /etc/apache2/dav_svn.passwd
>   AuthType Basic
>   AuthName "Lenny Subversion Repository"
>
>   AuthUserFile /etc/apache2/dav_svn.passwd
>
>   # To enable authorization via mod_authz_svn
>   #AuthzSVNAccessFile /etc/apache2/dav_svn.authz
>
>   # The following three lines allow anonymous read, but make
>   # committers authenticate themselves.  It requires the 'authz_user'
>   # module (enable it with 'a2enmod').
>   #
> #Require valid-user
>   #
> *
> *  Require valid-user*
> *
> 
> *
> By the way, all three of the above files in /etc/apache2/mods-enabled are
> actually symbolic links to the same file name in ../mods-available.
>
> I used sudo htpasswd to create the /etc/apache2/dav_svn.passwd file:
> *andy:4izmp7W8TSqww*
>
> Also I created my subversion directory like this:\
> *sudo bash
> mkdir /data/svn
> chmod a+w /data/svn*
> *ls /data/svn
> **drwxrwxrwx 2 root root 4096 2011-07-21 10:53 /data/svn*
>
> Now I point my browser to http://localhost/svn and I get a prompt for a
> user name and password. If I type in my valid user name "andy" and a
> completely spurious password, I get prompte

Re: Subversion access control

[Geoff Hoffman]

>
>
>
> On Wed, Jul 20, 2011 at 9:14 PM, Andy Canfield 
> wrote:
>
>> **
>> Thank you very much.
>>
>>
>> On 07/20/2011 12:19 PM, Nico Kadel-Garcia wrote:
>>
>> On Tue, Jul 19, 2011 at 11:14 PM, Andy Canfield 
>>  wrote:
>>
>>  One thing has hit my mind today that I don't think you realize ...
>>
>> I have never, in my entire life, seen a working Subversion system.
>>
>> Apparently Subversion, as distributed, doesn't work - the access
>> authentications are deliberately turned off.
>>
>>  I'm afraid it depends on your access requirements. Seriously. Which
>> access technology are you using? svn+ssh (which I tend to recommend),
>> or Apache (using https://), or svn directorly (svn://) Start with that
>> and we'll walk you through it.
>>
>>
>> OK, here goes.
>>
>> I would like to use http/https. I am not supposed to be working on the
>> server, but on my notebook workstation. And svn or svn+ssh require port 3690
>> to be forwarded by the router, and we don't own the router. So I would
>> prefer http and/or https.
>>
>> But on the actual server https is screwed up because mod_dev_svn.so is a
>> year earlier than Apache, and apparently there is a version mismatch. When
>> svn is enabled apache is dead. I have put in a request for my friend to
>> re-install, but that could take a week.
>>
>> So for the interim I have installed mod_dav etc. on my notebook computer.
>> FYI it is running Ubuntu Linux 1.04. This is for testing.
>>
>> Directory /etc/apache2/modes-enabled contains the file dav.load with this
>> contents:
>> *LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so*
>> That same directoy also contains the file dav_syn.load with these
>> contents:
>> *# Depends: dav
>> LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so
>> LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so
>> *
>> That same directory also contains the file dav_svn.conf which I altered;
>> this is the altered contents:
>> *# dav_svn.conf - Example Subversion/Apache configuration
>> #
>> # For details and further options see the Apache user manual and
>> # the Subversion book.
>> #
>> # NOTE: for a setup with multiple vhosts, you will want to do this
>> # configuration in /etc/apache2/sites-available/*, not here.
>>
>> #  ... 
>> # URL controls how the repository appears to the outside world.
>> # In this example clients access the repository as http://hostname/svn/
>> # Note, a literal /svn should NOT exist in your document root.
>>
>> 
>>
>>   # Uncomment this to enable the repository
>>   DAV svn
>>
>>   # Set this to the path to your repository
>>   #SVNPath /var/lib/svn
>>
>>   # Alternatively, use SVNParentPath if you have multiple repositories
>> under
>>   # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2,
>> ...).
>>   # You need either SVNPath and SVNParentPath, but not both.
>>   #SVNParentPath /var/lib/svn
>>   SVNParentPath /data/svn
>>
>>
>>   # Access control is done at 3 levels: (1) Apache authentication, via
>>   # any of several methods.  A "Basic Auth" section is commented out
>>   # below.  (2) Apache  and , also commented out
>>   # below.  (3) mod_authz_svn is a svn-specific authorization module
>>   # which offers fine-grained read/write access control for paths
>>   # within a repository.  (The first two layers are coarse-grained; you
>>   # can only enable/disable access to an entire repository.)  Note that
>>   # mod_authz_svn is noticeably slower than the other two layers, so if
>>   # you don't need the fine-grained control, don't configure it.
>>
>>   # Basic Authentication is repository-wide.  It is not secure unless
>>   # you are using https.  See the 'htpasswd' command to create and
>>   # manage the password file - and the documentation for the
>>   # 'auth_basic' and 'authn_file' modules, which you will need for this
>>   # (enable them with 'a2enmod').
>>   #AuthType Basic
>>   #AuthName "Subversion Repository"
>>   #AuthUserFile /etc/apache2/dav_svn.passwd
>>   AuthType Basic
>>   AuthName "Lenny Subversion Repository"
>>
>>   AuthUserFile /etc/apache2/dav_svn.passwd
>>
>>   # To enable authorization via mod_authz_svn
>>   #AuthzSVNAccessFile /etc/apache2/dav_svn.authz
>>
>>   # The following three lines allow anonymous read, but make
>>   # committers authenticate themselves.  It requires the 'authz_user'
>>   # module (enable it with 'a2enmod').
>>   #
>> #Require valid-user
>>   #
>> *
>> *  Require valid-user*
>> *
>> 
>> *
>> By the way, all three of the above files in /etc/apache2/mods-enabled are
>> actually symbolic links to the same file name in ../mods-available.
>>
>> I used sudo htpasswd to create the /etc/apache2/dav_svn.passwd file:
>> *andy:4izmp7W8TSqww*
>>
>> Also I created my subversion directory like this:\
>> *sudo bash
>> mkdir /data/svn
>> chmod a+w /data/svn*
>> *ls /data/svn
>> **drwxrwxrwx 2 root root 4096 2011-07-21 10:53 /data/svn*
>>
>> Now I point my browser to http://localho

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Daniel Neuberger]

On Thu, Jul 21, 2011 at 11:01 AM, Daniel Shahaf  wrote:
> ls -ald $REPOS_DIR $REPOS_DIR/hooks/ $REPOS_DIR/hooks/pre-commit

$ ls -ald repos/testrepo repos/testrepo/hooks/ repos/testrepo/hooks/pre-commit
drwxrwxrwx 7 svnuser svnuser 4096 Jul 20 13:03 repos/testrepo
drwxrwxrwx 2 svnuser svnuser 4096 Jul 21 05:31 repos/testrepo/hooks/
-rwxrwxrwx 1 svnuser svnuser   44 Jul 21 05:15 repos/testrepo/hooks/pre-commit

Since nothing else was working, I gave full permissions to everyone,
but it's still not working.  Thanks.

- Daniel

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Konstantin Kolinko]

2011/7/21 Daniel Neuberger :
> In short, we have a repository owned by one user that is accessed by
> tunneling over ssh to other user accounts.

Can't comment on this.

> The hooks work fine though if I ssh to the user account that owns the
> repository rather than another user account (we can't operate that way
> though).

> All the scripts are bash scripts.  All systems are RHEL 5.5 using svn 1.4.

The scripts have execute permissions for those other users?

Maybe svn cannot find bash to execute those scripts? Consider what
happens when you run with empty PATH.  One known example is the tasks
run by cron.

Have you looked into system-wide logs (for issues like SELinux warnings)?


Best regards,
Konstantin Kolinko

Re: Subversion access control / Linux users etc.

[Geoff Hoffman]

On Thu, Jul 21, 2011 at 4:54 AM, Andy Canfield wrote:

> **
> More user/command interaction -
>
> The commands to create the Subversion Repository Parent directory were
> *sudo bash
> mkdir /data/svn
> chmod a+w /data/svn*
> This created this directory:
> *drwxrwxrwx 4 root 4096 2011-07-21 17:36 /data/svn/*
>
> I ran this command as user root:
> *svnadmin create /data/svn/sample*
> and what I get is
> *drwxr-xr-x 6 root 4096 2011-07-21 11:08 /data/svn/sample/*
>
> I ran this command as user andy:
> *svnadmin create /data/svn/example*
> and what I got is
> *drwxr-xr-x 6 andy 4096 2011-07-21 17:36 /data/svn/example/*
>
> It concerns me that apache is running as user 'www-data' and niether of
> these repositories are owned by, or even writable by, www-data. So I did
> these commands:
> *sudo bash
> su www-data
> svnadmin create geronimo*
> The output of the last command was as follows:
> *svnadmin: Repository creation failed
> svnadmin: Could not create top-level directory
> svnadmin: Can't create directory 'geronimo': Permission denied*
> That surprises me; the /data/svn directory is writable by everyone. Ah
> well.
>
> The browser, when pointing to http://localhost/svn/RepoName, gives this
> answer
> *RepoName - Revision 0: /
> Powered by Subversion version 1.6.12 (r955767)*.
> This is true whether RepoName is 'sample' or 'example'. Of course, the only
> thing mod_dav_svn needs to do in this case is to read the repository, and
> all files and directories are readable by everyone, regardless of whether
> they are owned by root or andy.
>
> So the browser access mechanism has no commands to control a repository,
> only to describe it? Logically this might make sense; however I would expect
> that http://localhost/svn would be capable of listing the repositories and
> creating new repositories.. But when I point the browser to
> http://localhost/svn I get this response:
> *Forbidden
> You don't have permission to access /svn/ on this server.
> Apache/2.2.17 (Ubuntu) Server at localhost Port 80*
> When I look at /var/log/apache2/error.log I see these lines:
> *[Thu Jul 21 17:54:04 2011] [error] [client 127.0.0.1]
> Could not fetch resource information.  [403, #0]
> [Thu Jul 21 17:54:04 2011] [error] [client 127.0.0.1]
> (2)No such file or directory: The URI does not contain the name of
> a repository.
>  [403, #190001]*
> Ahah! So http://localhost/svn is NOT a valid Subversion URL. I was
> mistaken when I thought someone said that the Apache browser interface could
> give me a list of the repositories.
>
> PROBLEMS WITH THE 'SVN' COMMAND -
> As Linux user 'andy'. Here goes:
> *rm -rf .subversion
> ****svn info http://localhost/svn/sample --username='andy'
> --password=not-shown'*
> *Password for 'default' GNOME keyring:
> svn: OPTIONS of 'http://localhost/svn/sample': authorization failed:
> Could not authenticate to server: rejected Basic challenge (
> http://localhost)
> *The fact is that, as far as I know, I DON"T HAVE ANY %$#@! GNOME KEYRING!
> So when it asked for the Password for 'default' GNOME keyring I just pressed
> Enter. Then authenticiation failed.
>
> OK, so I have completely removed the gnome-keyring package. I also had to
> wipe out the ~/.gnome2/keywrings directory. Now to try again.
>
> Wait. Wait some more. Go down to 7/11; buy a hot dog and some potato chips.
> Come back home. It's been 20-30 minutes. Command still hasn't completed.
> Nothing in /var/log/apache2/error.log. Just a dead svn program. Had to kill
> -9.
>
> When it comes to plants, some people have a green thumb; I have a brown
> thumb. Looks like when it comes to Subversion I have a black thumb.
>
>

I feel for you, Andy. I had all these same problems you're having. The whole
gnome-keyring thing is a bad decision IMO, or at least, to use only
gnome-keyring or kwallet. Why they didn't leave the default password storage
options from 1.4x is a mystery. You are definitely not the first person to
have confusion and issues over this.

>From what I read they changed the behavior between Subversion server 1.4 to
1.5/1.6 to use this new/different authentication scheme. I never fixed that
on my server, either, on my server. I'm running Ubuntu Server 10.04 LTS and
there is no desktop so there is no gnome keyring. I just keep saying 'no'
when it asks to store plaintext passwords, and have to enter my password
every command I do. This is okay for me because 95% of the commands I run
are not on the server but from a remote client, and my IDE, both of which
store my password for me.

http://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/

If *you are not* concerned about the security issues surrounding storing
plaintext passwords, then you can enable that option in the [global] section
of your /etc/subversion/servers file:

store-plaintext-passwords = yes

If *you are* concerned about secu

Re: Subversion access control / Linux users etc.

[Thomas Harold]

The issues with passwords is why we ended up going with SSH public-key 
authentication.  Load the SSH key into the SSH agent, unlock it with the 
passphrase, then don't worry about it again until we reset the SSH agent 
at logout.


Less prompts, happier users.

(Plus it makes it harder to get into our servers since we don't allow 
password authentication.)

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Daniel Neuberger]

On Thu, Jul 21, 2011 at 11:16 AM, Konstantin Kolinko
 wrote:
> The scripts have execute permissions for those other users?
Yes.

> Maybe svn cannot find bash to execute those scripts? Consider what
> happens when you run with empty PATH.  One known example is the tasks
> run by cron.
The same script works though when logging into the repo-owner account,
so I don't think that's the problem.  Also, the full path is specified
in the hashbang.  Obviously, setting the PATH in the script wouldn't
change anything, do you have other ideas though?

> Have you looked into system-wide logs (for issues like SELinux warnings)?
Yes and there's nothing of interest.

Thanks!

- Daniel

Re: Can I prevent a file from being modified?

[Andreas Krey]

On Thu, 21 Jul 2011 11:06:00 +, David Weintraub wrote:
> I have a pre-commit hook that allows you to set a directory as
> "add-only". This was mainly for the tags directory. You can create a
> tag, but once created, it can't be modified.

The devil's advocate wants to know it this script accidentally also
allows adding new files/directories *within* a tag; thus getting
interesting results when accidentally executing

   svn cp $base/trunk $base/tags/blub -m "$message"

twice (a directory named trunk within the tag).

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Nico Kadel-Garcia]

On Thu, Jul 21, 2011 at 11:05 AM, Daniel Neuberger
 wrote:
> On Thu, Jul 21, 2011 at 10:51 AM, Nico Kadel-Garcia  wrote:
>> Stop *RIGHT* there. Go grab the Subverson 1.6.x from the RHEL updates.
>> Do not pass go, do not collect $200 until you do this sitewide.  There
>> are significant security and performance improvements, well worth the
>> update pain.
> Okay, we plan to do that asap, but it will take at least a little
> time.  In the meantime, there's no reason to believe that's causing my
> problem though, right?
>
>> That said, putting "suid" bits on svnserve is just begging for
>> confusing pain in a configuration that no one has been using. Can you
>> not use the svn+ssh shared account access, with SSH keys restricted to
>> svnserve tunnel access, as documented in the Subversion Red Book?
> That's what we're doing but the repository is owned by a separate user
> as an additional security measure so that if someone somehow gains
> shell access to the shared account, they won't be able to delete the
> repository or anything like that.  Do you think there's anyway to make
> it work this way?
>
> Thanks for the help.

Don't give the shared "svn" user a valid shell If an administrator
needs to run operations as that user, to manipulate config files or
create new repositories, they can do "sudo -s -H -u svn" to get a
valid shell as the administrative user. Sudo can even be configured to
allow designated users such administrative access without requing
local root privileges at all.

It's common to set the permissions of all files, except the "db"
directory and its contents, to "read-only" for the shared user, even
making them root owned to protect them, and I've heard of leaving a
cron job that locks down the individual revisions to avoid just what
you describe. But there's limits, and setting svnserve to "suid" or
"sgid" is not something I've seen anyone actually try. I'm afraid
that, for example,  it's not properly handling the limited shell
access necessary to run the "pre-commit" tasks in your setup.

Re: Subversion access control / Linux users etc.

[Ryan Schmidt]

On Jul 21, 2011, at 06:54, Andy Canfield wrote:

> The browser, when pointing to http://localhost/svn/RepoName, gives this answer
> RepoName - Revision 0: /
> Powered by Subversion version 1.6.12 (r955767).
> This is true whether RepoName is 'sample' or 'example'. Of course, the only 
> thing mod_dav_svn needs to do in this case is to read the repository, and all 
> files and directories are readable by everyone, regardless of whether they 
> are owned by root or andy.

Looks normal to me. It's showing you there is a repository, and it is empty.


> So the browser access mechanism has no commands to control a repository, only 
> to describe it?

It shows you the contents of the HEAD of the repository. There are also URL 
parameters you can add to look at previous revisions of files. But that's about 
it. If you want more detailed views into your repository, install a tool 
dedicated to that purpose, like WebSVN, Trac or ViewVC.

http://www.websvn.info/

http://trac.edgewall.org/

http://www.viewvc.org/


> Logically this might make sense; however I would expect that 
> http://localhost/svn would be capable of listing the repositories

It is. You need to add "SVNListParentPath On" to your httpd configuration. Just 
as directory listings are off in Apache by default for security reasons, so 
showing a list of repositories is off by default in Subversion.


> and creating new repositories.

Sorry, that's not a feature of the mod_dav_svn web interface. Administration 
functions, like creating and deleting repositories and users, is expected to be 
done by the sysadmin on the command line of the server. If you want a web 
interface for that, there are other administration-oriented web interfaces you 
could install, like SVNManager.

http://svnmanager.org/

Re: Subversion access control

[Ryan Schmidt]

On Jul 20, 2011, at 23:14, Andy Canfield wrote:

> I would like to use http/https. I am not supposed to be working on the 
> server, but on my notebook workstation. And svn or svn+ssh require port 3690 
> to be forwarded by the router, and we don't own the router. So I would prefer 
> http and/or https.

First of all, svn:// protocol uses port 3690, yes (or whatever port svnserve is 
listening on), but svn+ssh:// protocol uses port 22 (or whatever port sshd is 
listening on).

Second, what does a router have to do with this? You can't access the server 
directly from the client? You have to go through a router's port forwarding?

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Daniel Neuberger]

On Thu, Jul 21, 2011 at 2:13 PM, Nico Kadel-Garcia  wrote:
> Don't give the shared "svn" user a valid shell If an administrator
> needs to run operations as that user, to manipulate config files or
> create new repositories, they can do "sudo -s -H -u svn" to get a
> valid shell as the administrative user. Sudo can even be configured to
> allow designated users such administrative access without requing
> local root privileges at all.

Hmm, why didn't I think of that?  It doesn't seem to work though.
Setting the shell to /bin/nologin or even just fakeshell breaks
everything.  Is there another way to give an invalid shell?

Re: empty pre-commit hook fails with svn+ssh with some accounts

[David Chapman]

On 7/21/2011 4:00 PM, Daniel Neuberger wrote:

On Thu, Jul 21, 2011 at 2:13 PM, Nico Kadel-Garcia  wrote:

Don't give the shared "svn" user a valid shell If an administrator
needs to run operations as that user, to manipulate config files or
create new repositories, they can do "sudo -s -H -u svn" to get a
valid shell as the administrative user. Sudo can even be configured to
allow designated users such administrative access without requing
local root privileges at all.

Hmm, why didn't I think of that?  It doesn't seem to work though.
Setting the shell to /bin/nologin or even just fakeshell breaks
everything.  Is there another way to give an invalid shell?




How about /bin/false?  This is the "shell" defined for all of the 
non-login (e.g. daemon) accounts on my machines.


--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA

Re: empty pre-commit hook fails with svn+ssh with some accounts

[Nico Kadel-Garcia]

On Thu, Jul 21, 2011 at 7:24 PM, David Chapman  wrote:
> On 7/21/2011 4:00 PM, Daniel Neuberger wrote:
>>
>> On Thu, Jul 21, 2011 at 2:13 PM, Nico Kadel-Garcia
>>  wrote:
>>>
>>> Don't give the shared "svn" user a valid shell If an administrator
>>> needs to run operations as that user, to manipulate config files or
>>> create new repositories, they can do "sudo -s -H -u svn" to get a
>>> valid shell as the administrative user. Sudo can even be configured to
>>> allow designated users such administrative access without requing
>>> local root privileges at all.
>>
>> Hmm, why didn't I think of that?  It doesn't seem to work though.
>> Setting the shell to /bin/nologin or even just fakeshell breaks
>> everything.  Is there another way to give an invalid shell?
>>
>>
>
> How about /bin/false?  This is the "shell" defined for all of the non-login
> (e.g. daemon) accounts on my machines.

Depends on local system requirements. "/sbin//nologin" is common for
system accounts, such as "www-data" and "named" on UNIX and Linux
ystems, that don't need root access nor a valid user shell. It can
even be listed in /etc/shells as a valid shell to permit certain
oddball authentication setups to work well.

Subversion user problem?

[Andy Canfield]

I ran into a problem with a web site I am developing under Drupal; a 
problem related to user. And I suspect that the same problem arises witn 
Subversion.


On my local copy of that site, sometimes the PHP code creates a 
directory and puts files into that directory.  The directory had 
standard permissions - readable by all but writable only by owner. But 
that directory is owned by www-data because apache/PHP created the 
directory.


But when I zip it up, upload it to the server in Hong Kong, and unzip 
it, all directories are owned by the user on the server who unzipped the 
directory. The permissions were preserved; still readable by all but 
writable only by the owner. But the owner was no longer the Apache user, 
it was the user who unzipped the directory. I had to invent two shell 
scripts; one to run on my computer finding all the directories owned by 
Apache on my machine, and the second run on the server making all those 
directories writable by all.


I suspect that if I were using Subversion I would still have that 
problem. I do not remember seeing anything in the manual about 
preserving directory and file attributes, such as readable by all and 
writable by all. I do not remember seeing anything in the manual about 
directory owners. I saw no warning, I saw no assurance.


But, then again, I haven't finished the second manual yet. Maybe that's 
covered farther back in the book.


So does Subversion preserve directory attributes?

Re: Subversion user problem?

[Ryan Schmidt]

On Jul 21, 2011, at 20:31, Andy Canfield wrote:

> I ran into a problem with a web site I am developing under Drupal; a problem 
> related to user. And I suspect that the same problem arises witn Subversion.
> 
> On my local copy of that site, sometimes the PHP code creates a directory and 
> puts files into that directory.  The directory had standard permissions - 
> readable by all but writable only by owner. But that directory is owned by 
> www-data because apache/PHP created the directory.
> 
> But when I zip it up, upload it to the server in Hong Kong, and unzip it, all 
> directories are owned by the user on the server who unzipped the directory. 
> The permissions were preserved; still readable by all but writable only by 
> the owner. But the owner was no longer the Apache user, it was the user who 
> unzipped the directory. I had to invent two shell scripts; one to run on my 
> computer finding all the directories owned by Apache on my machine, and the 
> second run on the server making all those directories writable by all.
> 
> I suspect that if I were using Subversion I would still have that problem. I 
> do not remember seeing anything in the manual about preserving directory and 
> file attributes, such as readable by all and writable by all. I do not 
> remember seeing anything in the manual about directory owners. I saw no 
> warning, I saw no assurance.
> 
> But, then again, I haven't finished the second manual yet. Maybe that's 
> covered farther back in the book.
> 
> So does Subversion preserve directory attributes?

No, Subversion does not store permissions or ownership.

Re: Subversion user problem?

[Nico Kadel-Garcia]

On Thu, Jul 21, 2011 at 9:31 PM, Andy Canfield  wrote:
> I ran into a problem with a web site I am developing under Drupal; a problem
> related to user. And I suspect that the same problem arises witn Subversion.
>
> On my local copy of that site, sometimes the PHP code creates a directory
> and puts files into that directory.  The directory had standard permissions
> - readable by all but writable only by owner. But that directory is owned by
> www-data because apache/PHP created the directory.
>
> But when I zip it up, upload it to the server in Hong Kong, and unzip it,
> all directories are owned by the user on the server who unzipped the
> directory. The permissions were preserved; still readable by all but
> writable only by the owner. But the owner was no longer the Apache user, it
> was the user who unzipped the directory. I had to invent two shell scripts;
> one to run on my computer finding all the directories owned by Apache on my
> machine, and the second run on the server making all those directories
> writable by all.

Well, yes. The person who unzips a file, or untars it, or does an
rsync, or restore, or cpio, or "svn checkout", or any kind of "extract
this file from that bunch of information about files and create it
locally" operation, normally only has permissions to create files
owned by them. This is built into most filesystems, and only local
"root" or certain administritive users will have permission to erset
ownership.

That's really basic to how Linux and UNIX filesystems work. NTFS and
ZFS and other network filesystems have their own ideas about this, but
"I can only create files owned by me unless I have extra special
privileges" is the rule.


> I suspect that if I were using Subversion I would still have that problem. I
> do not remember seeing anything in the manual about preserving directory and
> file attributes, such as readable by all and writable by all. I do not
> remember seeing anything in the manual about directory owners. I saw no
> warning, I saw no assurance.

Because it's not something Subversion even tries to record. It would
be very, very sensitive to filesystems and operating system and get
really nasty really fast, and it also wasn't really bult into CVS
(which is the spiritual ancestor of Subversion). And it would be a
*nightmare* to attempt to apply or enforce. Setting that kind of
permissions is part of what a software installer would do, not
typically part of what a source control would do.

> But, then again, I haven't finished the second manual yet. Maybe that's
> covered farther back in the book.
>
> So does Subversion preserve directory attributes?

Only the "svn:executable" bit for files, and Subversion specific
settings such as "svn:externals" referring to the contents of the
directory.

Re: Subversion user problem?

[Andy Levy]

On Thu, Jul 21, 2011 at 21:31, Andy Canfield  wrote:
> I ran into a problem with a web site I am developing under Drupal; a problem
> related to user. And I suspect that the same problem arises witn Subversion.
>
> On my local copy of that site, sometimes the PHP code creates a directory
> and puts files into that directory.  The directory had standard permissions
> - readable by all but writable only by owner. But that directory is owned by
> www-data because apache/PHP created the directory.
>
> But when I zip it up, upload it to the server in Hong Kong, and unzip it,
> all directories are owned by the user on the server who unzipped the
> directory. The permissions were preserved; still readable by all but
> writable only by the owner. But the owner was no longer the Apache user, it
> was the user who unzipped the directory. I had to invent two shell scripts;
> one to run on my computer finding all the directories owned by Apache on my
> machine, and the second run on the server making all those directories
> writable by all.

Use tar to package your files for transport, and it'll preserve the
ownership & permissions when extracting, assuming you use tar
properly.

http://www.gnu.org/software/automake/manual/tar/Attributes.html

Re: Subversion user problem?

[Nico Kadel-Garcia]

On Thu, Jul 21, 2011 at 10:01 PM, Andy Levy  wrote:
> On Thu, Jul 21, 2011 at 21:31, Andy Canfield  wrote:
>> I ran into a problem with a web site I am developing under Drupal; a problem
>> related to user. And I suspect that the same problem arises witn Subversion.
>>
>> On my local copy of that site, sometimes the PHP code creates a directory
>> and puts files into that directory.  The directory had standard permissions
>> - readable by all but writable only by owner. But that directory is owned by
>> www-data because apache/PHP created the directory.
>>
>> But when I zip it up, upload it to the server in Hong Kong, and unzip it,
>> all directories are owned by the user on the server who unzipped the
>> directory. The permissions were preserved; still readable by all but
>> writable only by the owner. But the owner was no longer the Apache user, it
>> was the user who unzipped the directory. I had to invent two shell scripts;
>> one to run on my computer finding all the directories owned by Apache on my
>> machine, and the second run on the server making all those directories
>> writable by all.
>
> Use tar to package your files for transport, and it'll preserve the
> ownership & permissions when extracting, assuming you use tar
> properly.
>
> http://www.gnu.org/software/automake/manual/tar/Attributes.html

Not unless he is the root user (to reset ownership of extracted
files), the root user or a member of the groups (to reset groiup
ownership), and the underlying filesystem permits such settings (which
a FAT32, SSH on FUSE, or some other filesystems do not support).

Please don't gloss over the necessary underlying architecture when
giving an answer like that. For example, being able to extract files
and set ownership to root" as a normal user would imply being able to
extract "suid root" files as a normal file, meaning you could extract
a file that is owned by root and runs as root and can therefore do
*anything* without having other special privileges.

This actually ties to Subversion security issues I've noticed in the
past. People use Subversion for system configurations, source code and
Apache setups and cron jobs and setup tools, that get run as root.
Then they say "ohh, we trust the people we work with!!!" and "we have
a firewall" and "if someone is inside our network, we have a lot
bigger problems than this!!!" And they ignore security of
configuration tools that can set passwords, install SSH keys, open
firewalls, or simply "rsync /emptydir/ / --delete" and cause endless
havoc. (I've had that last one happen in a badly written shell script
by a developer who caught the consequences early, but almost wiped out
databases on NFS shares.)

svnadmin failure on nearly identical system

[Andy Canfield]

I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. 
I have the same system installed on my desktop computer named Athol (I 
had a lot of trouble getting that hardware to work). I have installed 
the Ubuntu Subversion packages on each; namely

subversion
libapache2-svn
libgirepository-1.0-1
In both cases the SVNParentPath is /data/svn and that directory is owned 
by www-data:

*drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn*

Here is the critical command:
*sudo -u www-data svnadmin create /data/svn/boofar*
On Lenny the command works, silently. On Athol I get this message:
*   svnadmin: error while loading shared libraries: libsvn_repos-1.so.0:
 cannot open shared object file: No such file or directory*
Apparently svnadmin cannot find something, but I don't know what it 
can't find. In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic 
link to:
*-rw-r--r-- 1 root root 153700 2011-06-05 22:48 
/usr/lib/libsvn_repos-1.so.1.0.0*


I Googled for that error message and somebody had a problem with the 
home directory locations. The implication was that for some reason a 
Subversion distribution hard-codes the name of the home directory parent 
path (e.g. "/home"). No problem with my home directories; the 
arrangement is identical. On both machines my home directory is 
/data/andy and /home/andy is a symbolic link to /data/andy.


So any idea why svnadmin runs OK on one machine and fails on the other?

Re: svnadmin failure on nearly identical system

[Ryan Schmidt]

On Jul 21, 2011, at 22:09, Andy Canfield wrote:

> I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. I 
> have the same system installed on my desktop computer named Athol (I had a 
> lot of trouble getting that hardware to work). I have installed the Ubuntu 
> Subversion packages on each; namely
> subversion
> libapache2-svn
> libgirepository-1.0-1
> In both cases the SVNParentPath is /data/svn and that directory is owned by 
> www-data:
> drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn
> 
> Here is the critical command:
> sudo -u www-data svnadmin create /data/svn/boofar
> On Lenny the command works, silently. On Athol I get this message:
>svnadmin: error while loading shared libraries: libsvn_repos-1.so.0:
>  cannot open shared object file: No such file or directory
> Apparently svnadmin cannot find something, but I don't know what it can't 
> find. In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to:
> -rw-r--r-- 1 root root 153700 2011-06-05 22:48 
> /usr/lib/libsvn_repos-1.so.1.0.0
> 
> I Googled for that error message and somebody had a problem with the home 
> directory locations. The implication was that for some reason a Subversion 
> distribution hard-codes the name of the home directory parent path (e.g. 
> "/home"). No problem with my home directories; the arrangement is identical. 
> On both machines my home directory is /data/andy and /home/andy is a symbolic 
> link to /data/andy.
> 
> So any idea why svnadmin runs OK on one machine and fails on the other?

Is there perhaps a second (older) copy of Subversion or its libraries 
installed, perhaps provided by your distribution? If so, try uninstalling that.

Re: svnadmin failure on nearly identical system

[Les Mikesell]

On 7/21/11 10:09 PM, Andy Canfield wrote:


*sudo -u www-data svnadmin create /data/svn/boofar*
On Lenny the command works, silently. On Athol I get this message:
*   svnadmin: error while loading shared libraries: libsvn_repos-1.so.0:
  cannot open shared object file: No such file or directory*
Apparently svnadmin cannot find something, but I don't know what it can't find.
In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to:


Is that a typo?  The error was about libsvn_repos-1.so.0.

--
  Les Mikesell
   lesmikes...@gmail.com

Re: svnadmin failure on nearly identical system

[Andy Canfield]

On 07/22/2011 10:20 AM, Ryan Schmidt wrote:

On Jul 21, 2011, at 22:09, Andy Canfield wrote:


I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. I have 
the same system installed on my desktop computer named Athol (I had a lot of 
trouble getting that hardware to work). I have installed the Ubuntu Subversion 
packages on each; namely
 subversion
 libapache2-svn
 libgirepository-1.0-1
In both cases the SVNParentPath is /data/svn and that directory is owned by 
www-data:
 drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn

Here is the critical command:
 sudo -u www-data svnadmin create /data/svn/boofar
On Lenny the command works, silently. On Athol I get this message:
svnadmin: error while loading shared libraries: libsvn_repos-1.so.0:
  cannot open shared object file: No such file or directory
Apparently svnadmin cannot find something, but I don't know what it can't find. 
In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to:
 -rw-r--r-- 1 root root 153700 2011-06-05 22:48 
/usr/lib/libsvn_repos-1.so.1.0.0

I Googled for that error message and somebody had a problem with the home directory 
locations. The implication was that for some reason a Subversion distribution hard-codes 
the name of the home directory parent path (e.g. "/home"). No problem with my 
home directories; the arrangement is identical. On both machines my home directory is 
/data/andy and /home/andy is a symbolic link to /data/andy.

So any idea why svnadmin runs OK on one machine and fails on the other?

Is there perhaps a second (older) copy of Subversion or its libraries 
installed, perhaps provided by your distribution? If so, try uninstalling that.

Nope; I installed subversion on Athol yesterday, and I run apt-get 
upgrade frequently.


UPDATE - ANOTHER TEST

I used 'tar' to move /data/svn/sample3 - an existing repository - from 
Lenny to Athol. Now I can point my browser to http://athol/svn/sample3 
and see the usual status screen. For command on Lenny:

*svn info http://localhost/svn/sample3*
The response is:
*Authentication realm:  Lenny Subversion Repository
Password for 'andy':
Path: sample3
URL: http://localhost/svn/sample3
Repository Root: http://localhost/svn/sample3
Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011)
*FOr this command on Lenny:
*svn info http://athol/svn/sample3*
The response is:
*Authentication realm:  Athol Subversion Repository
Password for 'andy':
Path: sample3
URL: http://athol/svn/sample3
Repository Root: http://athol/svn/sample3
Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011)*
But this command on Athol:
*svn info http://localhost/svn/sample3
*gives this error result:
*vn: error while loading shared libraries: libsvn_client-1.so.0:
cannot open shared object file: No such file or directory*

*So the problem is in the client, not on the apache server.
And both svnadmin and svn show the same problem.*

Re: Subversion access control

[Andy Canfield]

Thank you very much

On 07/20/2011 10:27 PM, Geoff Hoffman wrote:

Andy,

I thought you were off Apache and onto svnserve. Anyway, I sent you 
this info last week - maybe you missed it.  It is pasted again below. 
I will grant to you that it is tricky to set up. The david winter blog 
post below spells it out perfectly... for a single repo setup, 
multiple users. For multi-user, multi-repo setup see my pasted config 
files below. One thing to note that is confusing is that if your repos 
are at /subversion/repos/repo1 your  stays the same. 
The /svn bit there is what appears in the URL address bar, its not a 
filesystem path.


I have 10 repositories, project1 through project10, physically located 
on Ubuntu filesystem at

/svn/project1
/svn/project2
...
/svn/project10


Here is my /etc/apache2/mods-available/dav_svn.conf (the comments come 
with the file. This was installed using apt-get on Ubuntu 10.04 LTS.)



  # Uncomment this to enable the repository
  DAV svn

  # Set this to the path to your repository
  #SVNPath /svn
  # Alternatively, use SVNParentPath if you have multiple repositories 
under
  # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, 
...).

  # You need either SVNPath and SVNParentPath, but not both.
  SVNParentPath /svn
  SVNListParentPath on
This was the line missing from my config file; It allows me to see the 
overall pictures. Thanks!


  # From 
http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl


  #Order deny,allow
  Deny from all
  Satisfy any

Makes sense. I changed mine to fit yours.


  # Access control is done at 3 levels: (1) Apache authentication, via
  # any of several methods.  A "Basic Auth" section is commented out
  # below.  (2) Apache  and , also commented out
  # below.  (3) mod_authz_svn is a svn-specific authorization module
  # which offers fine-grained read/write access control for paths
  # within a repository.  (The first two layers are coarse-grained; you
  # can only enable/disable access to an entire repository.)  Note that
  # mod_authz_svn is noticeably slower than the other two layers, so if
  # you don't need the fine-grained control, don't configure it.

  # Basic Authentication is repository-wide.  It is not secure unless
  # you are using https.  See the 'htpasswd' command to create and
  # manage the password file - and the documentation for the
  # 'auth_basic' and 'authn_file' modules, which you will need for this
  # (enable them with 'a2enmod').

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd

  # To enable authorization via mod_authz_svn
  AuthzSVNAccessFile /etc/apache2/dav_svn.authz

  # The following three lines allow anonymous read, but make
  # committers authenticate themselves.  It requires the 'authz_user'
  # module (enable it with 'a2enmod').
  #
 Require valid-user
  #



Now, here is my /etc/apache2/dav_svn.authz file.


[groups]
group1 = usera, userb, userc, userd, usere
group2 = userc, userb
group3 = userf, userg
group4 = usera, userb, userc, userd, usere, userf
group5 = userh


[/]
@group1 = rw
@group2 =
@group3 =
@group4 =
@group5 =

[project1:/]
@group1 = rw

[project2:/]
@group1 = rw
userg = rw
userf = rw

[project4:/]
@group1 = rw

[project5:/]
@group11 = rw

[project6:/]
@group1 = rw
@group5 = rw

[project7:/]
@group1 = rw

[project8:/]
@group1 = rw

[project9:/]
@group1 = rw

[project10:/]
@group1 = rw
@group4 = rw

I notice that you don't have any entries that read "... = r"; everyone 
who can read can write also. No need?


There is no need to send you the dav_svn.passwd - it merely lists 
usera through userh with their hashed password. You use the htpasswd 
program to set your users up.


Here is the email I sent before...

I read (skimmed) all your posts, and I'm a little confused but I think 
I know where you're going. I'm not sure if you're using Apache to 
serve your repositories. If you are, you should check out this: 
http://davidwinter.me/articles/2006/03/03/access-control-for-subversion-with-apache2-and-authz/ 


and this https://help.ubuntu.com/community/Subversion

I recently followed the blog above and got everything setup how I 
think you want it. You can control user access to multiple repos in 
three ways, the blog explains it all, except one thing. I found that 
this is for folder-level control on one repository:


|[/]
@team = r
bob = rw

[/wowapp/trunk]
@team = r
@devteam = rw
brenda = rw|

In my authz control file, multiple repositories are done like this 
(note the repo name and colon):


|[repoA:/]
@team = r
bob = rw

[repoB:/]
@team = r
@devteam = rw
brenda = rw|

I also put websvn on it, and use the configuration option
Looks interesting; I installed it. Lots of configuration to do; will do 
later.


$config->useAuthenticationFile('/path/to/your/authz/file');

which I found on this stackoverflow QA 

Re: Subversion: existing users

[Andy Canfield]

On 07/21/2011 09:33 PM, Nico Kadel-Garcia wrote:

On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfield  wrote:

ADDENDUM ...

I used root to create the /data/svn directory. Then, anticpiating problems,
I did a chmod to make it writable to all.

Later I ran svnadmin create /data/svn/sample and it created an entire
repository directory tree under /data/svn. I don't remember but I probably
ran it as root.

I just now noticed that /data/svn/sample and all the sub-directories and
files therein are owned by root and, usually, writable only by root. This is
probably going to cause problems for Apache / mod_dav_svn which, of course,
runs as the 'apache user' ("www-data") instead of root.

Where did I go wrong? The manual talks about commands but does not seem to
talk about what user is executing the command. Do I have to run svnadmin as
www-data? Is there a way to create a repository using my browser?

Welcome to sys-admin hell, the "documentation is true, but not
complete" world that I've spent so many years in. The connections
between different pieces of information that are obvious to someone
who's been through similar issues in the past are not obvious to a an
intelligent but new person like yourself.
Yes. But don't forget "The documentation was true, then, but may not be 
true any more". I once googled for how to install Tomcat and the first 
web page I hit said that I had to recompile Apache myself. Written in 2002.



It goes back to "what are you trying to achieve". If you're setting up
an svn+ssh repository with direct user logins, various components need
to be owned with "write" permissions for those users. This is
typically done by putting users in a particular authorized group, such
as "project1" for the "project1" repository at /var/svn/project1. The
configuration files, such as /var/svn/project1/conf/ and
/var/svn/project1/scripts, can be owned by any user or group, as long
as the connecting user has appropriate read or execute access.



If you're setting it up for web access, it needs to have the writable
/var/svn/project1/db directory writable by whatever user runs the HTTP
daemon, typically "apache" or "www-data" on modern Linux systems. If
you're setting up both web access  and svn+ssh, your life becomes more
interesting and we could review that. It's tricky to do well.
I got that impression, after lots of agony over user group permissions 
on the repositories.

/var/svn/project1/db directory needs write access for the users. All
of them. When you use the kind of shared permission access you've
selected based on active local logins, you've given up control of that
directory to all the local users. It is theoretically possible to set
up cron job that scans that directory and resets ownership to a local
"svn" user of all successfully loaded revisions, and set the directory
permissions to 1777 to prevent users deleting each other's revisions,
but without such chicanery you cannot defend this file in that kind of
"shard access" setup.
My current impression is that the /var/syn/project/... directories need 
write access to whatever system user is running the service; either 
apache/mod_dav_svn.so or svnserve. Hell breaks loose when you have to 
use direct access to use svnadmin. Since websvn is said to work, and 
websvn runs under Apache, it should be happy with the same system user 
ownership as apache/mod_dav_svn.so likes.



This is also where you get into trouble with your ideal of "locking
down individual files". Individual working copy files aren't stored in
the database, they are *assembled* from the list of revisions involved
in modifying that file throughout that file's history. This is partly
why the most viable Subversion models of preventing individual file or
difectory modifications are all in the pre-commit stages, not in the
database structure itself.

And unfortunately, this sort of chicanery is not replicated for
backups: if you run "svnadmin hotcopy" to copy your repository, it
will not preserve the funky ownerships, and you'll need to deal with
it again.

Andy, it really sounds like you're getting caught up in the small
details. What *must* you have? Access for everyone with a valid system
login, or a designated list of users? Can your people use SSH keys,
which can seriously simplify ownership issues, and will HTTPS access
serve their needs?
The group I'm with right now only has three members, and this is the 
server for our organization, and so everyone happens to have a login on 
that server.


Obviously a server tends to have lots of different users, doing lots of 
different things. A centralized login authentication system is 
desirable. And for my experience, on a single machine server, that's the 
standard OS user login. It works for ssh and sftp and ftp. No need to 
memorize three passwords, no need to set up three different 
authentication files.


Unfortunately http and MySQL don't authenticate that way, so we have to 
set up parallel systems. 'htpasswd' is just another vers