Bug 425203

I've been thinking. maybe we should remove guest support from the UI.

windows doesn't allow guest access out of the box and on posix systems it's also fairly garbage because writes made by the guest are effectively made by a configurable pseudo account 'nobody'. this can lead to guests creating files that the owner of the directory cannot delete anymore because they are owned by nobody:nobody for example.
instead I'd set Everybody to full access in the ACL by default and have some info in the dialog somewhere that tries to at least explain, roughly, that share ACLs apply on top of file system ACLs and so share ACLs can be fairly liberal with fullaccess.

Food for thought perhaps.

As for the issue at hand: I'm not sure how to visualize in the gui but checking whether guest access is enabled is but a function call away.

hmm, giving everybody access by default doesn't seem good, maybe I've misunderstood you.

q.e.d. I guess ;)

abcde <- assume each character is a user and 'e' is everyone
rwf-r <- share ACL
      <- the user is logged in on the share now
f---- <- filesystem ACL (e.g. posix chmod bits)
      <- the user can do file operations on the share
f---- <- the files

The effective access granted to a=f, b=-, c=-. It is that way because the share ACL can not give you permissions you do not posses on the filesystem. Whatever is on the filesystem line trumps whatever is on the share line. The share ACL can take rights away though:

abcde <- assume each character is a user and 'e' is everyone
rwf-d <- share ACL
      <- the user is logged in on the share now
f---- <- filesystem ACL (e.g. posix chmod bits)
      <- the user can do file operations on the share
----- <- the files

Here nobody can do anything because everyone was denied to log into the share e=d. The filesystem plays no part, the users aren't get let into samba. So what you could do is mirror the filesystem ACL and that'd be working with least astonishment:

abcde <- assume each character is a user and 'e' is everyone
f---- <- share ACL
      <- the user is logged in on the share now
f---- <- filesystem ACL (e.g. posix chmod bits)
      <- the user can do file operations on the share
f---- <- the files

That leads to a=f and everyone else cannot log into samba. That is the truest ACL but makes no sense practically, you now have to maintain the same ACL in two different places.
And that finally gets us to defaulting to everyone:fullaccess by default:

abcde <- assume each character is a user and 'e' is everyone
----f <- share ACL
      <- the user is logged in on the share now
f---- <- filesystem ACL (e.g. posix chmod bits)
      <- the user can do file operations on the share
f---- <- the files

You'll note that is the same as the first example albeit with zero complexity on the share ACL level. Most importantly though the only ACL that the user now actually needs to care about is the filesystem.

abcde <- assume each character is a user and 'e' is everyone
----f <- share ACL
      <- the user is logged in on the share now
f-r-- <- filesystem ACL (e.g. posix chmod bits)
      <- the user can do file operations on the share
f-r-- <- the files

Now c can read.

abcde <- assume each character is a user and 'e' is everyone
----f <- share ACL
      <- the user is logged in on the share now
f-rr- <- filesystem ACL (e.g. posix chmod bits)
      <- the user can do file operations on the share
f-r-- <- the files

Now d can read.

...

The only times where you want a restrictive share ACL is when the filesystem you share doesn't have a permission system or the filesystem permissions aren't quite right but also cannot be fixed for whatever reason.
So everyone:fullaccess doesn't give full access, it merely gives the users the same level of access that they have when they log in locally. It does mean that users only need to worry about the actual filesystem ACL, not the share ACL.

Thanks! However I'll admit I'm having trouble following your examples. This seems like an extraordinarily complicated permissions system. I don't think regular users will have a prayer of a chance of understanding this unless we abstract away most of that complication and present a subset of the features/permissions that can actually make sense and won't conflict with one another.

(In reply to Nate Graham from comment #4)
> Thanks! However I'll admit I'm having trouble following your examples. This
> seems like an extraordinarily complicated permissions system. I don't think
> regular users will have a prayer of a chance of understanding this unless we
> abstract away most of that complication and present a subset of the
> features/permissions that can actually make sense and won't conflict with
> one another.

Yep. I have been saying a simple "share this" wizard would be nicer for most people. But until someone makes one I'd kick out the guest option out (since it isn't enabled by default upstream anyway) and make fullaccess the default for Everyone. Full access effectively does what a full on "share this" wizard would do, it takes the share permissions out of the equation.

With everyone:fullaccess the rule of thumb is: give your directory and files the permissions so the people you want to have access can have access, shares need no special set up.

ohhhh turns out ksambashare already has all the code, the qwidget ui just didn't use it properly :O

Hah!

A possibly relevant merge request was started @ https://invent.kde.org/network/kdenetwork-filesharing/-/merge_requests/12

Git commit c1ff8b3ae814167517c333cf8bd0d5958974005d by Harald Sitter.
Committed on 24/08/2020 at 15:41.
Pushed by sitter into branch 'master'.

only enable guest checkbox if the smb.conf allows it

uses new ksambshare to check guest configuration and disable the
checkbox if guest support is enabled. also shows an info label
explaining why the box is disabled
FIXED-IN: 20.12

M  +11   -0    samba/filepropertiesplugin/qml/ACLPage.qml
M  +6    -0    samba/filepropertiesplugin/sambausershareplugin.cpp

https://invent.kde.org/network/kdenetwork-filesharing/commit/c1ff8b3ae814167517c333cf8bd0d5958974005d