Add storage permissions to UserDetail

[hannesdejager]

This extends the UserDetail trait with a storage_permissions method that allow storage back-ends to limit what a user can do.

[asomers]

This looks pretty good to me. BTW some of these permissions don't correspond 1:1 to Capsicum rights. For example, GET and LIST would both require CAP_READ but nothing else. So the storage backend itself will also have to validate rights. But it would have to do that anyway, if we want the rights to be enforced on !FreeBSD.

Do you want a permission like STAT that allows the SIZE and MDTM commands? Or should they come along with LIST?

[asomers]

ping. What does this PR still need?

[hannesdejager]

ping. What does this PR still need?

Hey sorry @asomers , I've been so focussed on the book I'm writing I've neglected and forgotten about this. Will try to attend to it in the next couple of days.

[hannesdejager]

Related PR: #503

[hannesdejager]

The problem here is that this introduces a breaking change as such that all storage back-ends will need to be updated to make use of this, even the ones we don't have control over.

[asomers]

The problem here is that this introduces a breaking change as such that all storage back-ends will need to be updated to make use of this, even the ones we don't have control over.

Is it really a breaking change? Will the default implementation of UserDetail::storage_permissions not provide for backwards-compatibility?

[hannesdejager]

If a user implementation is passed in that returns something other than the default, full access implementation, then storage back-ends that don't handle this don't behave correctly.

I wonder if we can a UserDetail implementation with this functionality specifically in the filesystem back-end? I think you only rely on that right?

At least for now to unblock you.

How are you using this functionality, do you have your own FTP server that uses libunftp or do you want to eventually extend unFTP?

[asomers]

If a user implementation is passed in that returns something other than the default, full access implementation, then storage back-ends that don't handle this don't behave correctly.

Oh, I get it. Should we enforce these rights in libunftp itself then? Instead of the storage backend? That would fix the backwards-compatibility problem.

I wonder if we can a UserDetail implementation with this functionality specifically in the filesystem back-end? I think you only rely on that right?

The filesystem backend? Yes, I'm using that. Are you suggesting adding a UserDetail implementation just for purposes of testing the necessary backend changes?

At least for now to unblock you.

How are you using this functionality, do you have your own FTP server that uses libunftp or do you want to eventually extend unFTP?

I have my own FTP server based on crates/unftp-sbe-fs/examples/cap-ftpd.rs .

[hannesdejager]

Should we enforce these rights in libunftp itself then? Instead of the storage backend?
Most probably, and easiest is maybe to use a delegate pattern i.e. wrapping something like https://crates.io/crates/unftp-sbe-restrict around the given storage back-end by default and have to option to override it that behaviour and swap it out for e.g. capsicum in the storage back-end.

Are you suggesting adding a UserDetail implementation just for purposes of testing the necessary backend changes?
I wasn't thinking of testing but making it a feature of the storage back-end. But on second thought maybe thats not a great idea.

Would still be nice if this can be externally decided in a https://crates.io/crates/unftp-sbe-restrict way to keep libunftp core small