libsmbclient: how to see if authentication succeeded

[Willem van Engen]

On Wed, 2008-06-04 at 12:03 -0400, Derrell Lipman wrote:
> 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).
> 

The more obvious the solution, the harder to find; good point. After
some debugging and remembering SMBCCTX_FLAG_NO_AUTO_ANONYMOUS_LOGON,
I could see EACCES and EPERM appearing in the two cases, yay!

> 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.
>

I agree the errno solution would be best.

Just to be complete: I think we have a smbc_get_cached_srv_fn() that
does it already: (this would be the same as the first workaround I
mentioned before). The premise is that the presence of a cached
connection is equivalent to the authentication having succeeded.

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

*relief* ;)

> 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.

Thanks for clarifying.

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

Great, I really appreciate your knowledgeable reply.
I have something to work with again.

Kind regards,
- Willem