libsmbclient: how to see if authentication succeeded
Willem van Engen
dev-list-samba at willem.engen.nl
Thu Jun 5 14:46:44 GMT 2008
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.
> 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.
More information about the samba-technical