I’m syncing /etc folder (one way) from host A to host B using Syncthing. This copy of /etc (from host A) on host B is in turn being synced with Dropbox cloud storage. I noticed Dropbox sync process was stuck with the error
“Can’t sync shadow-” (access denied)
I guess it is caused by the fact that copy of /etc/shadow- file on host B has no permissions (000) and rightly so as the original file on host A has no permissions either.
Now, I’m curious how does Syncthing manage files with no permissions? I guess reading the original file on host A was possible as Syncthing runs as root on this host. However on host B Syncthing runs as non-root user. How would Syncthing handle file with no permissions in case it needed to be renamed/moved/deleted?
We create the file with normal umask, put the content in, set the permissions and rename (where rename needs permissions in the directory, not the file).
That’d be a security problem. What we actually do is create the temp file with the same permissions as the destination, plus user read&write so we ourselves can actually access it during the sync.
I’m not sure I’m following. To read a file with no permissions one has to first change its permissions and set read permission. As seen in my description Dropbox couldn’t read a file with no permissions so presumably it does not try to set read permission to handle no permissions scenario. Does Syncthing in the same case set read permission on such a file to be able to read it? I don’t see how creating a temp file would help here.
We do nothing special to read files with restrictive permissions. We are talking about the other side, creating files with restrictive permissions, answering the question
How would Syncthing handle file with no permissions in case it needed to be renamed/moved/deleted?
Your other question you answered yourself:
Now, I’m curious how does Syncthing manage files with no permissions? I guess reading the original file on host A was possible as Syncthing runs as root on this host.
Well, in fact I’d like to know how the whole “process” works which consists of two “phases”; phase one is reading a source file and phase two is writing destination file. Per your remark above I understand Syncthing can’t sync a file with no permissions as it isn’t able to read it. In other words Syncthing would have similar problem handling such a file as Dropbox has.
Knowing this I would like to ask two more questions;
Would Syncthing stuck on such a file similar to Dropbox or would it just “skip” such a file and proceed with syncing other files?
Shouldn’t Syncthing set read permission in case the source file’s owner is the same as the owner of Syncthing’s process (which I believe is the most common case)? Rationale for this would be that having no permissions on one’s file could be seen as a way to prevent accidental manual operation but should rather not prevent dedicated tools from performing their tasks.
It will continue syncing other things. When pulling in remote changes it will go into out of sync state and show the offending files. I assume but am not sure that there will be a warning when a file fails to be scanned as well.
I don’t think so: When system files have no permission there is probably a good reason. Syncthing is not a dedicated tool to manage such files, it is a general purpose file synchronization tool. Already changing the permission without doing any modification to the content can break a system.
If the file is unreadable I think it will just be an info level log entry on the scanning side. Since it can’t scan it I don’t think any update will be sent, so the other devices are none the wiser.
I see where you are coming from but would like to play devil’s advocate and make a case for different behavior. You say
When system files have no permission there is probably a good reason.
Yes, there probably is a good reason. However this reason probably makes sense in the context of working, live system. When we talk about synchronization we are in a quite a different context where the original reason (for lack of permissions) might no longer be such relevant. Think of synchronization tool such as Syncthing as an online version of partition/disk duplication and the subject of permissions suddenly is not so clear. What makes sense in the context of live system does not necessarily have to make sense when talking about synchronization of data. In other words I believe synchronization is kind of special operation and should not always abide by standard rules of live system. I think Window’s Shadow Copy makes a good example of what I’m trying to convey here; namely that there’s quite a difference between live system and its state in specific moment of time (snapshot).
To show how important it is to have some support from synchronization tool here please think for a moment what a user wanting to make a complete copy of some specific part of the system (/etc folder here) is supposed to do to achieve his goal? His only option would be to either make a static list of all files with no read permission, set read permission before synchronization and clear the permission after or better yet have a tool which would scan disk and do this automatically. But this clearly suggests it could/should be automatically handled by synchronization tool (which already has to scan all files and is well aware when a file is being synchronized so it can make appropriate adjustments before, and after the synchronization) itself.
In other words clearing all permissions on a file might be thought of as a simple and generic way to prevent random processes from operating upon such a file but at the same time this should not prevent the ability to grant specific processes (performing synchronization here) permission to do what others can not.
Syncthing is not a dedicated tool to manage such files, it is a general purpose file synchronization tool.
By dedicated I meant any tool run in non-interactive mode as opposed to issuing commands at the prompt. If something is a synchronization tool I should be able to direct it to synchronize my files and all my files regardless of any protection I deemed suitable for other processes.
Already changing the permission without doing any modification to the content can break a system.
I have hard time thinking of a case where changing permissions only to make a copy would break a system. Please remember we are talking here about scenario where the user running Syncthing process and the owner of a file is one and the same user. Nevertheless it would be nice if the system would provide a way to temporarily change permission of a file only in the context of specific process so that new permissions would be not visible to other processes. I’m not aware of any such a way, however.
Grant Syncthing CAP_DAC_OVERRIDE (or maybe just CAP_DAC_READ_SEARCH) and it’ll slice through your 0000 file permissions like butter. Modifying files we are only supposed to be reading is antisocial and may open them up for reading by others who should not have access.
Thanks for suggesting CAP_DAC_READ_SEARCH and CAP_DAC_OVERRIDE capabilities! This is just perfect way to grant specific processes (performing synchronization here) permission to do what others can not.