Per-user webdav directories
AkselMeola opened this issue · comments
Hey!
Have been playing with the Davis and so far everything is super nice.
As far as I can currently understand the web-dav dir is shared between all users.
Are there any plans to implement/support a per-user directories for web-dav?
(https://sabre.io/dav/per-user-directories/)
Thanks!
Hi @AkselMeola
This could be rather straightforward to have a /home dir but there are some directory / file rights shenanigans to address in my opinion.
Would you be able to try this branch #143 and tell me if everything seems to work for your use case?
Thanks. I'll have it a go.
So technically it works.
But the file permissions need to be tested further.
For example on the branch the webdav public dir is a parent node of the home node:
$nodes[] = new \Sabre\DAV\FS\Directory($this->webdavPublicDir);And this will allow all users to access all the users homes.
It could be somewhat mitigated with a separate public directory like this:
$nodes[] = new \Sabre\DAV\FS\Directory($this->webdavPublicDir . '/public');This just a test, it should probably be ENV config to choose between homes, public or both.. or smth. And provide a separate path for public for example.
But here also lies one bug: Any user can rename the "public" node and it will say it had an error, but on the filesystem it still actually renamed the dir. After refresh app has errors due to the missing path, so a disruption of service could be created.
When I tinkered with the Sabre on my own then due to the hideNodesFromListings being false I was able to also rename other user dirs, but that was likely due to some permissions mess up on my part.
Here I was not able to do such shenanigans, which is good, but I have not gone in deep to check what actually restricts it here and validate this is "safe" (..and even if the node is not visible).
TLDR:
I think you can close this for now, since there are probably some bugs in hiding, unless you want to go deep into it.
If I have more time I might tinker with it a bit further.
(I think OC must rely on something similar, so perhaps there is some easy config to fix the public dir rename issue and validate the homes are "safe").
Thanks for looking into it tho 👍
Ok. Sorry. Wrong alarm.
The public rename was due to the local file permissions. It can be fixed if the public path's parent is read-only.
E.g.:
/users/homes/{user1, user2, ... } (/users/homes +rw)
/users/public (/users/ -w)
This in itself is a small trap for admins tho and maybe a plugin or a rule could be made to not allow the rename action on public node.
Hi @AkselMeola
Not sure I get your example above. Having the home directory at the same level as the calendars or principals seems correct to me. Are you saying we should apply a specific right to WEBDAV_PUBLIC_DIR ?
Did some testing with this branch because this feature would be useful to me as well.
I set WEBDAV_PUBLIC_DIR=/var/lib/davis. Afterwards the personal home directory was accessible under https://domain.dom/dav/home/<user>/ as exptected. All home dirs were created correctly like /var/lib/davis/<user>/.
But I can also access all users home dirs with https://domain.dom/dav/davis/<user>/
I guess this should not be possible permission wise.
Hi @de-es
I guess this should not be possible permission wise.
Did you set the correct folder permissions as per @AkselMeola's message up there?
Sorry, I don't understand how to define a different home base dir other than the public dir. home or homes doesn't seem to be hardcoded, is it? Do I have to alter the code?
Sorry, I don't understand how to define a different home base dir other than the public dir
I am talking about the permission of the folder on your device, not changing the home (which indeed would need to alter the code)
Sorry for my ramblings.
-
The issue with users renaming the public dir can be fixed by not allowing the php/web user not make changes in the parent of public dir. (By default I had set it too wide permissions.)
-
The other issue where users can access other user homes is still relevant since the permission to access the public dir, which contains the 'homes', seems to override the home folder access. To fix this, it requires having a separate homes directory which is not a child of the public dir (or maybe there is some specific ACL that can be implemented, but unlikely).
I have updated #143 to differentiate the public directory from the homes directory, it should fix your second point if I'm not mistaken!
Sorry for the late reply. Separating homes from public did the trick. Works like a charm. www-data is allowed to write in both previous folders, but not in their parent.
👋🏼
I've finally merged #143 — disabling the home directories by default so that the behavior doesn't change from the existing.
Thanks @AkselMeola and @de-es for chiming and helping on this!