Issue 595 get to remote repo fails when upstream directory permisions are restrictive

Title get to remote repo fails when upstream directory permisions are restrictive
Priority bug Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, jch, kowey, markstos, thorkilnaur, tommy
Assigned To markstos
Topics Darcs2, X_DeprecatedTopic_Testing

Created on 2008-01-19.01:44:10 by system, last changed 2009-10-24.09:09:53 by admin.

msg2565 (view) Author: markstos Date: 2008-01-19.01:44:08
I'll be 'sending' a test to bugs directory shortly which illustrates the
following weakness of darcs: 

darcs "get" may fail with a permissions error even when the current directory
has sufficient permissions, and the remote directory has sufficient permissions,
as well, but a parent directory of the current repo has restrictive permissions. 

This is the case on some web-server setups where "/home" has restrictive
permissions, but people may run darcs from "/home/user/www". 

By using "strace", I can see that the failure point is when "chdir" is called
with the full path of the current directory. An example failure message looks
like this:

darcs: /home/mark/Haskell/darcs-unstable-hashed/bugs/tmp_restrictive/liberal:
setCurrentDirectory: permission denied (Permission denied)

It seems the fix would have to involve avoiding the "chdir" call to the full
path of the current repo. 

The bug is triggered in darcs 1.0.9 and a current build of Darcs2.
msg2657 (view) Author: droundy Date: 2008-01-22.19:13:05
I'm skeptical of this bug.  Is it really not a broken system if we cannot chdir
into the repository directory? It's possible to fix this by only using relative
paths, but the reason we preferentially use absolute paths is because the use of
relative paths tends to be fragile, in the sense that they can easily lead to
bugs when small changes are made to the code.

A related question:  does situation invalidate *all* uses of absolute paths, or
only for certain operations like chdir? The only even moderately robust solution
I can imagine would be to replace all uses of setCurrentDirectory (and perhaps
all other FS access routines?) with one that checks the current directory and
computes from it a relative path to the absolute path we want to access.  It
sounds very fragile, and I'd really prefer not to take this approach.

So my leaning for this scenario would be to instruct users to run darcs in a
directory they have permissions to access with an absolute path.
msg2659 (view) Author: markstos Date: 2008-01-22.19:53:58
I think your skepticism is well founded.   I think the situation is 
reasonable. Our server is a fairly stock cPanel setup with restrictive 
permissions on /home:

$ ls -lthd /home
drwx--x--x  61 root  wheel   1.5K Jan 18 14:47 /home

However, these operations still succeed for me:

cd /home/whereiam/www

 perl -MCwd -e  'chdir "/home/shopdons/www/store"; print cwd();';

I can also "cd" to /tmp and "cd" back.

Is this possible a Haskell bug? or maybe darcs is just executing an 
unnecessary command on a parent directory. It might be useful for 
someone else to review the test script that triggers it, and perhaps 
review the "strace" output of the failure point.

msg2660 (view) Author: droundy Date: 2008-01-22.20:07:27
Okay, part of this trouble is that the test script sets permissions to 0000,
which is more restrictive than what you describe as reasonable restrictive
permissions on /home (which allow execute, but not read).

I think this is a test-script bug.  It seems that if I set the permissions to
0111 on the superdir, the test passes.  Any less permissions than that, and I
don't think darcs can be expected to function properly.

msg2662 (view) Author: markstos Date: 2008-01-22.20:20:59
Assigning to myself as test-script cleanup issue.
msg2666 (view) Author: markstos Date: 2008-01-23.00:14:25
David beat me to the test-cleanup work. (Thanks!). I'm going to consider this
"resolved" for now, since we now lack a test case which triggers an unresolved
Date User Action Args
2008-01-19 01:44:10systemcreate
2008-01-19 02:28:24markstoslinkissue130 superseder
2008-01-19 05:01:12markstoslinkissue119 superseder
2008-01-22 19:13:06droundysetstatus: unread -> unknown
nosy: + darcs-devel, jch
messages: + msg2657
2008-01-22 19:54:00systemsetnosy: droundy, jch, tommy, beschmi, kowey, darcs-devel, system
messages: + msg2659
2008-01-22 20:07:28droundysetnosy: droundy, jch, tommy, beschmi, kowey, darcs-devel, system
messages: + msg2660
2008-01-22 20:12:27droundysetstatus: unknown -> resolved
nosy: droundy, jch, tommy, beschmi, kowey, darcs-devel, system
topic: + X_DeprecatedTopic_Testing
2008-01-22 20:21:00markstossetstatus: resolved -> unknown
nosy: + markstos
messages: + msg2662
assignedto: markstos
2008-01-23 00:14:26markstossetstatus: unknown -> resolved
nosy: droundy, jch, tommy, beschmi, kowey, markstos, darcs-devel, system
messages: + msg2666
2009-08-06 17:51:45adminsetnosy: + jast, Serware, dmitry.kurochkin, zooko, dagit, mornfall, simon, thorkilnaur, - droundy, jch, system
2009-08-06 20:54:34adminsetnosy: - beschmi
2009-08-10 22:11:04adminsetnosy: + system, jch, - zooko, jast, dagit, Serware, mornfall
2009-08-25 18:03:08adminsetnosy: - simon
2009-08-27 13:53:00adminsetnosy: jch, tommy, kowey, markstos, darcs-devel, system, thorkilnaur, dmitry.kurochkin
2009-10-24 09:09:53adminsetnosy: - system