Feature: Option to pass-through Xattrs (like "com.dropbox.ignored") to the cipher file

[SentineI]

Hi

Can you please add an option to pass-through all xattrs to the underlying cipher files?

As it currently stands, I am not able to use Gocryptfs without -plaintextnames, because I need to mark certains folders (like __pycache__, .mypy_cache, .git, etc) as not synced by Dropbox (to avoid giving it indigestion & wasting space on stuff I don't need shared).

As far as I can see, Gocryptfs stores xattr encrypted, rather than passing them through:

~$ gocryptfs -version
gocryptfs v2.6.0-4-g33fa0b5 without_openssl; go-fuse v2.8.0; 2025-07-19 go1.22.2 linux/amd64
~$ mkdir TEST_CIPHERDIR TEST_MOUNTPOINT
~$ gocryptfs -init -plaintextnames TEST_CIPHERDIR
Choose a password for protecting your files.
Password: 
Repeat: 

Your master key is:

    XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-
    XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs TEST_CIPHERDIR MOUNTPOINT
~$ gocryptfs TEST_CIPHERDIR TEST_MOUNTPOINT
Password: 
Decrypting master key
DetectQuirks: Btrfs detected, forcing -noprealloc. See https://github.com/rfjakob/gocryptfs/issues/395 for why.
Filesystem mounted and ready.
~$ touch TEST_MOUNTPOINT/{test1,test2}
~$ attr -s com.dropbox.ignored -V 1 TEST_MOUNTPOINT/test1
Attribute "com.dropbox.ignored" set to a 1 byte value for TEST_MOUNTPOINT/test1:
1
~$ attr -g com.dropbox.ignored TEST_MOUNTPOINT/test1
Attribute "com.dropbox.ignored" had a 1 byte value for TEST_MOUNTPOINT/test1:
1
~$ attr -g com.dropbox.ignored TEST_CIPHERDIR/test1
attr_get: No data available
Could not get "com.dropbox.ignored" for TEST_CIPHERDIR/test1
~$ attr -g com.dropbox.ignored TEST_CIPHERDIR/test2
attr_get: No data available
Could not get "com.dropbox.ignored" for TEST_CIPHERDIR/test2
~$ fusermount -u TEST_MOUNTPOINT
~$ rm -rvf TEST_CIPHERDIR TEST_MOUNTPOINT

[lquenti]

sounds like a reasonable issue, would like to work on it myself as it seems quite trivial, @rfjakob would you be open to the idea? If so, should it just be another FeatureFlag (-plainxattrs)?

[rfjakob]

Yes, could be a featureflag, and i like the name.

The question is if having all xattrs unencrypted is desirable. What do you think @SentineI ?

[rfjakob]

(There may be data in the xattrs that you don't want to leak unencrypted)

[SentineI]

The question is if having all xattrs unencrypted is desirable. What do you think @SentineI ?
(There may be data in the xattrs that you don't want to leak unencrypted)

It appears that Dropbox doesn't sync arbitrary xattrs (just a select few), so for my use case unencrypted xattrs would not be a problem. But for other (non-cloud) uses it might be, so I think xattrs should be encrypted by default (i.e. only optionally passed through).

I wasn't sure what kind of data actually gets stored in xattrs, so I ran this recursive scan of my ~ folder:

~$ getfattr -dhRP -- ~ 2>/dev/null | grep -vE "^#|^$" | cut -d= -f1 | sort -u
user.com.dropbox.attrs
user.com.dropbox.foldericon
user.com.dropbox.ignored
user.DOSATTRIB
user.gocryptfs.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1
user.gocryptfs.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2
user.gocryptfs.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3
user.overlay.impure
user.overlay.opaque
user.overlay.origin
user.overlay.uuid
user.wine.sd
user.Zone.Identifier

They don't seem too concerning, but I could then check exactly what data a particular type of xattr contained & for what files, for example:

getfattr -dhRP -m ^user.Zone.Identifier -- ~ 2>/dev/null | less

An unencrypted "user.Zone.Identifier" might be a problem for some people, since it says something about where a file was downloaded from (apparently). So yes, xattrs should still be encrypted by default.

[SentineI]

Of course it would be nice if we could use a regex pattern to control what xattrs to pass through unencrypted, but in software development I feel it's better to only implement what's needed now, rather than what might possibly be needed by some unknown future users (that might not even exist).

But perhaps you could internally store the -plainxattrs option as something like xattrs_to_passthrough=.*? That way if you ever want to support a regex pattern, you won't need to read/write two different internal config parameters (the old one & the new one).

[rfjakob]

The dropbox link is interesting, thanks. Looks like macos store comments and tags there. We don't want to leak these.

The simplest way to support this would be a mount flag (i.e. not stored in the config file), similar to -exclude.

Storing such details in the config is also problematic as the config is neither encrypted nor authenticated.

[lquenti]

I have to say that I never used reverse mode before, very neat though!

But I don't quite understand how not encrypting xattrs would work (in a user friendly way) with a mount time flag...

-exclude seem to work because the other files are just omitted, right? And next mount, when they are not omitted anymore, the encrypted mount is not in an invalid state, since it is not the persistent version that is changed.

When doing it on the forward mode dir, I am too stupid to understand how it does not break things.

• I mount it with -excludexattrs "com.*", then I touch a file and add the com.dropbox.ignored=foo attribute (plain) and the dc.author=me (ciphered)
• Then I remount it, this time I forget the -excludexattrs flag. I then iterate over all xattrs for my file, and see a broken xattr, or even worse by chance, a wrongly decrypted one.

It feels like the same problem of "throwing a plain file into the cipher folder, and then decrypting again, except that we don't even have two magic bytes at the beginning that tell us "this is our file". If I am just a bit stupid right now, I am sorry

[SentineI]

The simplest way to support this would be a mount flag (i.e. not stored in the config file), similar to -exclude.

My worry about doing that was what xattrs do you return when you have a xattrs stored on both the cipher file & plain file?

The simplest solution I can think of is: If your mount option says to pass (all) xattrs through (storing them on the cipher files), then you only read xattrs from the cipher files. And if you have no mount option, then it behaves as it currently does (reading xattrs from the decrypted/plain files).

lquenti raises the issue of what happens if you forget the mount option one time. I guess tough luck! Or write a script to scan all decrypted/plain files for xattrs (without the mount option), saving into a temporary text file, and maybe deleting xattrs from the plain files, then remount with the correct mount options, and then apply the xattrs to the plain files again (so they now get correctly stored on the crypt files).