bolcom
Add a UserDetail::read_only method
If it returns True, then the storage backend should not allow any destructive operations. Implement this method in the cap-ftpd example for unftp-sbe-fs.
Also, use Capsicum within unftp-sbe-fs, on FreeBSD. After authenticating a connection, limit the process's rights to mitigate any potential attacks.
Hi @asomers , terribly sorry for not answering you here. I saw this at some point but then forgot about it when life got busy.
I don't think this is the right approach. Instead of adding readonly capabilities to each storage back-end individually, we should do it only once. This is what I am doing here: https://github.com/hannesdejager/unftp-sbe-restrict
Can this be used for your purposes?
The crate is here: https://crates.io/crates/unftp-sbe-restrict
Let me know your thoughts.
Hi @asomers , terribly sorry for not answering you here. I saw this at some point but then forgot about it when life got busy.
I don't think this is the right approach. Instead of adding readonly capabilities to each storage back-end individually, we should do it only once. This is what I am doing here: https://github.com/hannesdejager/unftp-sbe-restrict
Can this be used for your purposes?
The crate is here: https://crates.io/crates/unftp-sbe-restrict
Let me know your thoughts.
Functionally, I think it would work. It wouldn't provide capability-based security, though. The nice thing about this PR is that Capsicum guarantees that, after StorageBackend::enter gets called, there's no way for the backend to modify any files even if we mess up some of the coding. Using unftp-sbe-restrict that wouldn't be possible, because the real storage backend wouldn't know about the user's permissions. Or is there another way to communicate that information?
I think the capsicum code in enter is the right approach. What I don't think is, is adding the read_only method to UserDetail.
Maybe I don't understand where you're going with that but at least it seems the addition of read_only and checking for that in the storage back-end need not be coupled with the capsicum additions?
If UserDetail doesn't include read_only , then how would enter know whether it needs capsicum::Right::Write ?
Right... I'm asleep after a long day. I have to think a bit on this... perhaps we need to bring the granularity of permissions that is implemented in unftp-sbe-restrict to libunftp itself i.e. have a permissions method on UserDetail and not just support readonly
Right... I'm asleep after a long day. I have to think a bit on this... perhaps we need to bring the granularity of permissions that is implemented in unftp-sbe-restrict to libunftp itself i.e. have a
permissionsmethod on UserDetail and not just supportreadonly
That sounds like a good idea.
Something like this: https://github.com/bolcom/libunftp/pull/511
@robklg what do you think?