Issue 2726 darcs should not hard-link files owned by another user

Title darcs should not hard-link files owned by another user
Priority urgent Status unknown
Milestone Resolved in
Superseder Nosy List bfrk
Assigned To

Created on 2024-06-01.12:34:33 by bfrk, last changed 2024-06-02.11:49:16 by bfrk.

msg23925 (view) Author: bfrk Date: 2024-06-01.12:34:32
This is a pretty bad one.

We currently treat all hashed files as eligible for hard-linking even if 
they are owned by another user. This can lead to strange failures (e.g. 
when the other user changes permissions) and may even be a potential 
security risk.

I think this is mostly due to some recent changes I made in order to 
increase sharing of hashed files. In fact I have now checked that after 
pulling a single patch from a repo of another user we hard-link most of 
our hashed files to those of the other user.
msg23926 (view) Author: ganesh Date: 2024-06-01.20:02:54
If darcs always does a integrity check when reading a hashed file,
it might not be a security risk. Not 100% sure though and better
safe than sorry.
msg23927 (view) Author: bfrk Date: 2024-06-02.08:03:08
Hmm, I think I agree with your assessment wrt security. These are hashed 
files after all and AFAIK darcs always checks that the hash matches the 

That said, ending up with files not owned by yourself in your private 
cache or repositories can become a practical problem in case the other 
user removes our read permission.

Unfortunately this is not easy to fix because there is currently no 
portable way to check for file ownership. While the Win32 API does have 
a procedure for that, the result is an internal structure which is *not* 
part of the Win32 API, but rather belongs to kernel API (winnt.h), and 
the Haskell Win32 package does not yet expose the full API to get at the 
owner ID inside the structure (the naked foreign calls are in the 
sources but are not referenced anywhere). I guess similar problems will 
occur with getting the user ID of the current process.

This means that fixing this is going to require us to make a PR for 
Win32 to add the missing features. Then we need to define a portability 
layer for this, possibly contributing that to unix-compat (though I 
suspect this may be controversial since it would add considerable 
overhead to getFileStatus on Windows).

msg23928 (view) Author: ganesh Date: 2024-06-02.10:32:47
If the risk is inconvenience rather than security, I wouldn't worry
too much about it - I wouldn't expect it to be all that common
nowadays to be cloning repos on the local filesystem on a machine
that is really multiuser. And it seems even less likely with Windows.

That said, this Windows behaviour doesn't look good:
msg23929 (view) Author: bfrk Date: 2024-06-02.11:49:16
Ugh, this is bad indeed. It means "deleting" your cache destroys all 
your repos; irrecoverably so if you also empty the wastebin afterwards. 
Would it be possible for you to test that (with a new disposable user 
account, of course)?

BTW, we do use multi-user development hosts at work (Linux).
Date User Action Args
2024-06-01 12:34:33bfrkcreate
2024-06-01 20:02:55ganeshsetmessages: + msg23926
2024-06-02 08:03:09bfrksetmessages: + msg23927
2024-06-02 10:32:48ganeshsetmessages: + msg23928
2024-06-02 11:49:16bfrksetmessages: + msg23929