libsmbclient: how to see if authentication succeeded - Samba

This is a discussion on libsmbclient: how to see if authentication succeeded - Samba ; > libsmbclient has, to date, been a intended for POSIX-like functionality. > Since there is no login function that would be emulated, there's been no > reason for such a function. We have, however, recently had some requests > for ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: libsmbclient: how to see if authentication succeeded

  1. libsmbclient: how to see if authentication succeeded


    > libsmbclient has, to date, been a intended for POSIX-like functionality.
    > Since there is no login function that would be emulated, there's been no
    > reason for such a function. We have, however, recently had some requests
    > for non-POSIX-like features. I recently reorganized the libsmbclient code
    > with a couple of things in mind, one of them being additional ease of adding
    > non-POSIX-like functionality.

    Ah, I see.

    > In your case I'm not sure it's necessary, though. libsmbclient itself does
    > not issue two separate authentication attempts. If it doesn't find an
    > existing connection, it calls your registered authentication function to
    > retrieve username/password data. There is no initial call across the wire
    > with invalid or "anonymous" authentication information. If you're seeing
    > multiple requests, I believe that's probably your application doing it, not
    > libsmbclient. I just confirmed the behavior I'm describing using wireshark
    > and the examples/libsmbclient/testacl test.
    >
    > Maybe I'm not understanding the issue correctly?

    smbc_stat() behaves correctly and only requests credentials once.

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

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

    Either I want to use a workaround that has your blessing, or else
    inquire if such functionality could be added to libsmbclient. I'd be
    happy to write a patch [3].

    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.

    Kind regards,
    - Willem


    [1] One might argue if I really need to know if login succeeded or not.
    I'm trying to fix a bug in gvfs (the new gnome virtual i/o layer),
    and that knows something like mount-ing a filesystem. On mount, for
    example, the samba filesystem may be fuse-mounted too. Also, the
    user might want to know if a password was wrong, or if it's just
    that is has no access to the requested directory but login
    succeeded.

    [2] I happen to have a share at hand that has no permission on the the
    share's root, but it has on subdirectories.

    [3] A simple approach would be to expose the login function, or a
    wrapper for it. Current smbc calls will remain to work unmodified,
    and anyone wanting to check the authentication result can call the
    login function before running any smbc other commands.


  2. Re: libsmbclient: how to see if authentication succeeded

    On Wed, Jun 4, 2008 at 11:22 AM, Willem van Engen <
    dev-list-samba@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


  3. Re: libsmbclient: how to see if authentication succeeded

    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


+ Reply to Thread