Comment 14 for bug 24184

Huygens wrote:
> Thank you Eric for your work :-) that is a nice initiative.

Glad to be of help. I'm also making trouble in the anti-spam (reputation-based)
arena and small-scale Web frameworks (learn hours, not days or weeks), and
speech recognition-based accessibility.
>
> However, there is a caveat with your approach and the one taken in Bug
> 103708. The problem is that it tends to associate a share with a credential.
> Nevertheless, credentials in Samba are "samba-wide", meaning there can only
> be one login/password combination for all the shares in Samba. So if the user
> set a specific login for share A and define the password. When later he wants
> to create a new share (let's call it B), and he wants to access it using the
> same specific login, there is no need for him to use the same password. If we
> had the user credentials definition in the GUI that share a folder, we will
> make the end-user think that a credential is bound to a share, which is not
> the case in Samba configuration (apart a few exceptions like home
> directories).

Are you referring to the Ubuntu's Samba implementation or Samba in general? I
have set up Samba with different credentials for different shares and not just
with the home directory. This is why I thought about binding credentials to a
share. If you want to have multiple credentials associated with a share, Samba
has a way of creating groups.

As for associating a set of credentials with a share, I don't think that's bad.
  We need some mechanism that the user will be driven to to enter credentials
for sharing. If we don't do that, people will not set their share username and
password. Maybe, the user model would be forcing the user to enter a username
and password if there is none and giving them the option to set different
usernames and passwords if one exists.

The workflow would be something like:

Create the first share with Mandatory username password before accepting share
definition

Create second share

optional username password but user is notified of that option and given the
ability to set username and password on the share dialog box (don't make me
click another button please, my hands hurt)

>
> So a more logical place would be a central Samba configuration GUI like the
> one which can be found in System->Administration->Shared folders. Where you
> can click to set Samba-wide settings such as the domain/workgroup for the
> computer, etc. However, in the end-user logic, this is not the expected
> place, and if we put it here, I'm sure we will find countless forum posts
> about where to set Samba password.

Which is why it belongs on the user form to create a share. It's horrible but
one must always accept that the user hate surprises it wants to be led by the
nose. To those of us who grew up using command lines, it's anathema. To people
like my wife it's comfort.

> A work-around solution would be to present to a user when he first shares a
> folder a specific GUI where he can set Samba-wide parameters (such as the
> domain/workgroup and his credentials). There is however another caveat, which
> is when there are multiple user at home. If user A install Ubuntu and share
> folder /tmp. User B, who is using another machine on the network and who
> knows about the share, wants to access it. User B enters his login name and
> password and the access is refused. User A would then need to understand that
> he should create a local user named B and then create the Samba credentials.
> Unless he is an IT guy, this might not be obvious to him.

Exactly. It's even confusing to me at times until I slap my forehead etc.

> Another idea could be have a simplified sharing mechanism for home users.
> Where a guest account is activate by default so when a share is opened,
> people on their network can view them (but not modified them). Then we could
> imagine that the smbpasswd would be automatically created when a user is
> created (meaning also in the Ubuntu installation process). If a user set his
> login credentials, he could then access read/write the shares. There are some
> caveats to that, mainly for SOHO, Enterprises and enthusiasts where they do
> not want to have a smb account for each user they are creating. They probably
> do not want the guest account thing, etc.

That also has the serious privacy issues. I have stumbled across peoples
machines that are sharing the entire C drive and had access to their e-mail.
So, I'm really not comfortable with the guest idea especially if the user gets
to set the share directory. Another possibility if you're not comfortable with
my idea from above is to create a default username and password when the first
account is created so that if they share their own directories, they use their
own username and password. I'm not comfortable with that on a couple of levels
but I could live with it.

A third option is to add to the share dialog box a button labeled "share with
others". This box would bring up a spreadsheet like form listing in the first
column all the users, and the access permissions in the second column. this
form also gives you the ability to set passwords or change permissions for any
given user. The limitation of this model is sharing multiple shares and how do
you inherit username/password/permissions from another shared user list. I
would draw a sample but I think I would do it in HTML this time.

> So, I do not have solution to this problem. The approach of Windows (at least
> until XP, I have not seen Vista yet) is equally not satisfying, so we cannot
> get inspiration from there. As for how the case is handle on a Mac, I have no
> clue! What about the other Linux distro or the BSD*? Does anyone knows how it
> is done on them?

haven't looked lately. That's a really good question. Unfortunately, I will
have to defer to somebody else's knowledge/experience for the usual reasons.

take care
---eric

--
Speech-recognition in use. It makes mistakes, I correct some.