libsmbclient: how to see if authentication succeeded

[Derrell Lipman]

On Wed, Jun 4, 2008 at 11:22 AM, Willem van Engen <
dev-list-samba at willem.engen.nl> wrote:

>
> Maybe I should restate my problem: I want to know if authentication
> succeeded or not [1]. One could use smbc_opendir() or smbc_stat() on a
> known-readable path, but I have no path that is guaranteed readable [2].


Ok.  Let's first make sure we're not overlooking the obvious.  If you issue
smbc_opendir() or smbc_stat() and it fails for authentication reasons, errno
should be set to EPERM..  Does checking errno serve your purposes?

This solution can't be used to check a non-existent top-level share.
Attempting to call smbc_opendir()  using "smb://server/xyz" for example
(where share name "xyz" does not exist), even with invalid authentication
data, yields errno==ENOENT since share enumeration can occur prior to
connection establishment.  It does work fine for a real share name or for an
administrative share name like C$ (represented as C%24 in the URI string).

Now I have two workarounds to detect if libsmbclient authentication did
> work out:
> * Check the connection cache after the smbc operation. If an entry was
>  added, authentication succeeded - independent of the result of the
>  smbc call.


If the errno solution solves your problem, it should do much if not all of
what checking the connection cache would do.  I'd consider exposing a
function that returned whether a given
server/share/workgroup/username/password tuple has an existing connection,
but I really don't think that it provides more info than just checking
errno.


>
> * Do the smbc operation twice. If the authentication callback isn't
>  called the second time, authentication succeeded. This is what the
>  previous post was about; it was a reply to a suggestion made by
>  Andreas Schneider.


It really should not be necessary to issue a request more than once.  Let's
find a better solution.


> But your statement on future additions got me looking a bit harder in
> the mailing lists, and so I found the discussions for samba4. Is this
> idea still in the pipeline? If so, maybe I had better use the first
> workaround for now (since it's really an annoying bug that needs fixing)
> and wait for samba4 to fix it properly ... but not without your consent
> and knowing the current api is being (ab)used in this way.


Samba4 is a different beast.  It's got a fabulous design and is easy to
extend and work with.  It's a from-scratch implementation that takes
advantage of the years of knowledge on design issues gained with previous
samba versions.  It's not, however, quite ready for prime time, and
furthermore, there's been no work to date AFAIK on POSIX-like client code in
the vein of libsmbclient.  The interfaces for client use are really nice,
including easy async operation, but unless they were recently added, I
believe some features are still missing (e.g. browsing).  I don't believe
even the folks working feverishly on samba4 yet recommend using it for
production purposes.

I think we can find a good solution to your current issue either using the
existing libsmbclient API or with some simple additions.

Cheers,

Derrell