[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Réf. : Permission issue creating transations on Solaris (1.2.0, fsfs)

From: Yann DIRSON <yann.dirson_at_sagem.com>
Date: 2005-07-07 17:43:29 CEST

Hi,

For the record, the problem does not occur with a custom-built 1.2.1 on
Solaris 9.

Yann DIRSON

23/06/2005 17:22

 
        Pour : users@subversion.tigris.org
        cc : "Steven M. Christensen" <steve@smc.vnet.net>
        Objet : Permission issue creating transations on Solaris (1.2.0, fsfs)

I am using the 1.2.0 package from sunfreeware, for Solaris 9. I had no
problem whatsoever using the dbfs backend, using either 1.1.3 or 1.2.0.

I have created a repository in the fsfs format, I can load it with a dump
file, checkout from the repository through apache, but I get a "funny"
permission error on commit:

$ svn ci -m 'test fsfs'
svn: Commit failed (details follow):
svn: Can't open file
'/externe.u0/svn/foo/db/transactions/14-6.txn/node.0.0': Permission denied

That is, it creates the transaction directory, but cannot populate it. The
direct reason is the permissions on those transaction directories, lacking
an x bit:

% ls -l foo/db/transactions/
total 12
drw-rwSrw- 2 apache apache 512 Jun 16 10:56 14-1.txn
drw-rwSrw- 2 apache apache 512 Jun 16 11:09 14-2.txn
drw-rwSrw- 2 apache apache 512 Jun 16 11:09 14-3.txn
drw-rwSrw- 2 apache apache 512 Jun 16 13:37 14-4.txn
drw-rwSrw- 2 apache apache 512 Jun 16 13:38 14-5.txn
drw-rwSrw- 2 apache apache 512 Jun 16 13:39 14-6.txn

I could work around the problem by putting a default ACL on the
transactions/ directory:

% setfacl -m d:u::rwx,d:g::r-x,d:o:r-x foo/db/transactions/

And now on the client:

$ svn ci -m 'test fsfs'
Adding bar
Transmitting file data .
Committed revision 15.

I checked that the Debian/x86 package of 1.2.0 does not have this issue.

Looking at create_txn_dir() in libsvn_fs_fs/fs_fs.c, it looks like
svn_io_dir_make() is called with permissions APR_OS_DEFAULT, which should
cause it to obey the umask. Attaching a gdb to the any httpd process and
calling umask() seems to show the expected 022 value, which cannot explain
the problem.

Any idea ?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 7 19:34:13 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.