add: Detect when xattrs or perhaps ACLs prevent locking down a file's content

And fail with an informative message.

I don't think ACLs can prevent removing the write bit, but I'm not sure,
so kept it mentioning them as a possibility.

Should git-annex lock also check if the write bits are able to be removed?
Maybe, but the case I know about with xattrs involves cp -a copying NFS
xattrs, and it's the copy of the file that is the problem. So when locking
a file, I guess it will not be the copy.

Sponsored-by: Dartmouth College's Datalad project

doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_11_541e257ea04d6a7647a337998d79232c._comment

@@ -16,29 +16,29 @@ a file themselves with cp -a on this NFS and then git-annex adds the copy.
 Probably git-annex would then be unable to remove the write bit
 from the annex object file. 
 
-For that matter, the same could happen with ACLs. Eg, I was able to
-use setfacl to make this happen:
+I also worried about ACLS, but it seems like ACLs do not have this
+problem, because chmod a-w causes the write ACL that was set to be
+effectively unset:
 
 	joey@darkstar:~>chmod -w foo
 	joey@darkstar:~>setfacl -m g:nogroup:rw foo
 	joey@darkstar:~>ls -l foo
 	-r--rw-r--+ 1 joey joey 0 Aug 27 12:53 foo
-	joey@darkstar:~>chmod -w foo
-	chmod: foo: new permissions are r--rw-r--, not r--r--r--
-	- exit 1
-	joey@darkstar:~>perl -e 'chmod(400)' foo
+	nobody@darkstar:/home/joey$ echo test >> foo
+	joey@darkstar:~>chmod a-w foo
 	joey@darkstar:~>ls -l foo
 	-r--rw-r--+ 1 joey joey 0 Aug 27 12:53 foo
+	nobody@darkstar:/home/joey$ echo test >> foo
+	bash: foo: Permission denied
+	joey@darkstar:~>getfacl foo
+	# file: foo
+	# owner: joey
+	# group: joey
+	user::r--
+	group::r--
+	group:nogroup:rw-		#effective:r--
+	mask::r--
+	other::r--
 
-So git-annex would be unable to clear the write bit, and would not be able
-to effectively lock down the file for all users, eg user nobody can write
-to the file in the above example. There's probably a way to let user joey
-also write to it, but my attempt to do that with an ACL failed.
-
-Perhaps git-annex should clear ACLs when ingesting (and locking) files.
-But perhaps users use ACLs for other purposes that would not prevent
-lockdown, and so they should not be cleared. And as far as internal-use NFS
-xattrs, it doesn't seem wise for git-annex to try to unset them from files
-its ingesting. So I guess I'm going to punt on this broader question,
-if users want to use the ACL rope, it's over there..
+I've verified that git-annex add also clears the write ACL.
 """]]

doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_12_80b15bc4e0c8c9ed4680da9408c1d559._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-08-27T17:13:54Z"
+ content="""
+I've also made git-annex add check, after removing write bits,
+if the file still has write bits set. It will refuse to add a file
+when it can't lock it down.
+
+That should avoid the NFS xattr problem in a situation where
+cp -a was used to make a copy that then gets added to the annex.
+"""]]