bit-team
Change octal permissions on newly created backup directories to something other than 0777
New directories on my backup disk are being created with 0777 permissions. A little digging revealed that this is because the call to os.makedirs[0] in common/tools.py on line 108 has octal permissions of 0777 unless otherwise specified. It seems imprudent to have the backup directories be world-writable since then anyone can delete those files.
Can I suggest perhaps adding alternative permissions to the os.makedirs call? Something like 0750 would seem sensible to me: owner has full permissions, group members can see the contents and everyone else is excluded.
[0] http://docs.python.org/library/os.html#os.makedirs
Imported from Launchpad using lp2gh.
- date created: 2011-07-25T15:36:51Z
- owner: pwcazenave
- the launchpad url was https://bugs.launchpad.net/bugs/815966
(by pwcazenave) I've since realised that os.makedirs also uses the system umask value when no particular value is given, as such I'm not sure where the problem lies now. The temporary directory new_snapshot has the correct permissions on it. I think one of the chmod commands somewhere in snapshots.py is leaving the newly renamed snapshot directory with full 0777 permissions on it.
The question to me is why BIT explicit set "0777" instead of leaving it to the OS (using umask).
I've seen the same behavior (777). This definitely needs to be changed.
To my knowledge and experience there is no documentation about why 0777 is set. There is also no comment from someone giving an answer or idea about it. It seems to me that Germar (2nd generation maintainer of BIT) also does not know why. The 1nd generation maintainer and founder of BIT is not reachable. So we can not ask him.
If know one has a good reason to veto it I vote to remove that 0777 mask thing. But heavy manual(!) testing needs to be done after it. Our (unit) test suite does not cover enough details.
In short: My signal as maintainer is I am open to remove that behavior. Currently I see no resources for it. There are some other things higher on my todo list.
I consider 777 to be an obvious and significant security risk.
There's nothing to test there either. In a multi-user system, anyone can simply destroy the backup. After changing to at least 775, things that shouldn't work under any circumstances will simply stop working.
If you don't want to change it, then at least provide a notice to the users (e.g., in the readme or FAQ). They can then easily change it themselves (chmod 775).
Hello Blindes-Huhn, Thank you for your comment.
Again, I am open to modify it and see no obstacle not doing it. Wasn't that clear from my last comment?
There's nothing to test there either.
As maintainer this decision is up to my team and me. BIT is damn old, complex and a smelly bunch of code. Manual testing including a long release candidate period is mandatory because I am not able to see and judge all consequences of that modification. And my experience with BIT and other projects telling me that there is always something hidden.
If you don't want to change it,
That wasn't what I wrote. I am open for a change.
then at least provide a notice to the users (e.g., in the readme or FAQ). They can then easily change it themselves (chmod 775).
Good idea.
It would help if you could write such an FAQ entry. You can post it as a comment here in this issue or directly edit the FAQ.md and open a PR for it.
Additionally to a FAQ entry there could also be an entry in the Known problems section of the README.md, itself linking back to the FAQ entry.
This is my suggestion, feel free to change and use it everywhere:
Write permissions (777) on the backintime directory
A newly created backup is located in the backintime/<hostname> directory. These directories have write permissions for everyone (777). If you don't want these permissions, you can modify it:
cd /place/of/your/backup
chmod 775 backintime
cd backintime
chmod 775 <hostname>
In the latest dev version a new local backup folder is created with this permissions. Isn't it 0775?
drwxrwxr-x 3 user user 4,0K 25. Jun 16:10 20250625-161040-762/
Or are we talking about the next folder inside it named backup. Isn't it 0755?
drwxr-xr-x 3 user user 4,0K 19. Jun 08:28 backup/
To my research in the code base common/tools.py:mkdir() is not involved in creating the backup directory. Rsync itself does create that directory and will use the systems "default" permissions influenced by umask.
So I am asking if there still is a problem? And if BIT is able to do something about that problem?
EDIT:
This is not a final decision; just some unfinished thoughts.
The target group for BIT are desktop end users, in most cases on single user systems.
For this use case I see no high need to modify make BIT behave different from the configured umask. I mean the system sets the permissions based on the umask. Why should BIT modify that on such a system for such users?
For power users in different use cases I would expect that they are experienced and skilled. They should be able to modify the permissions of the directory them self via chmod.
I'm looking forward for your feedback and opinions about that.
EDIT2: If leaving it as it is, I would suggest to add a "Security" section in the user manual and simply mention the situation, its implications in different use cases and how to approach them.
I received no further feedback from someone else and also not from the Debian ticket. So the decision stands: The situation and its security implicates will be described in the manual but the behavior wont change.
Closing this ticket based on the comment above. Feel free to reopen if the problem still exists. Thank you for your efforts. If you have any further questions, ideas or encounter any other issues, please don't hesitate to let us know.
Best regards, Christian