ignore ext* readonly (i) and append-only (a)

[md-work]

Is there a way to ignore ext* (e.g. ext4) readonly and append-only attributes?
I couldn't find a way to ignore those attributes. Neither via standard Linux mount options, nor via bindfs.

I'd like to ensure full write access to a folder for all programs running as a certain user, while the bindfs process is running as root. Ignoring the unix permissions works fine via bindfs. But those ext* readonly and append-only attributes are still blocking.

If there's really no existing way to ignore those attributes, what about introducing an option to ignore them via bindfs?
If the bindfs process runs as root or has CAP_LINUX_IMMUTABLE, it can transparently remove those attributes in background from a file, when a program requests write access for that file. After file access ends, bindfs simply restores the attributes being set before. (or maybe there's even a technical way to do this without actually removing the attributes!?)

---

I'm talking about the attributes being set by:

chattr +a FILENAME
chattr +i FILENAME

I know I can use chattr -ai for a file before requesting write access. But there's a huge amount of files and I don't know which are being write accessed in advance. So doing chattr -ai in advance is no option.

Related: #37

[mpartel]

I'm not aware of any way to ignore them without unsetting them, and I'd be reluctant to add the feature to unset them temporarily as you suggested, since it sounds hacky and error-prone:

• if bindfs crashes or is killed, the attributes would not be restored
• in a situation where bindfs would temporarily unset them, I'd question the value of setting those attributes to begin with

It would seem cleaner to have bindfs simulate append-only for a given set of users (or all but a given set of users). Then have the things that need append-only access write through bindfs, assuming the performance impact isn't too great. Would that work in your case?

I don't have much free coding time at the moment, but I'd be happy to accept a pull request if you want it in a hurry. It'd entail: adding some flags in main (it's a bit fiddly), adding a check for O_APPEND in (edit: bindfs_create bindfs_open), writing a test, writing a man-page entry.

[md-work]

I think you got the meaning of append-only wrong. It's just a slight variant of read-only, which shouldn't be missed when writing code for handling read-only files. It's not a solution for software trying to write to read-only files.

# Sets read-only
chattr +i

# Sets append-only, which is quite the same like read-only (do 
# deletion, modification, rename) except programs are allowed to append 
# data at the end of the file.
chattr +a

---

I understand why you're reluctant to implement unsetting-resetting the attribute. But on the other hand there are scenarios where this can be needed and failures (flag not being reset afterwards) are acceptable. Think of handling USB thumbdrives where someone else gave "stupid" permissions to files and you don't want to be bothered with those permissions.

There could be a clear warning about using such a feature and it should be definitely off by default.

I you say you'd merge it, I may take the time to implement it this way (setting-unsetting the attribute).

A slight variant could also be to just unset the attribute where needed, without resetting the attribute.

[mpartel]

Oh, sorry, looks like I got fixated on append-only for no good reason.

I'm still struggling to think of scenarios where auto-unset or unset-reset is clearly better than just unsetting for all files before using them (e.g. with find ... -exec chattr ...). The USB thumbdrive example seems to be in the latter category, unless I'm missing something. Without a clear use-case, I wouldn't want to merge this feature, sorry.

However, you can probably add auto-unset to your own fork pretty easily: you can make the required ioctl calls* to unset the attributes in bindfs_open. It should be only a 1-2 line chage if you don't want to bother putting it behind a flag etc. And forking bindfs shouldn't be too bad since it changes very rarely these days.

(* If the ioctl parameters prove hard to google, they can be found out by printing them in bindfs_ioctl and running bindfs with --enable-ioctl -f.)