Bug 5580 - Unable to access DFS shares using libsmbclient
Summary: Unable to access DFS shares using libsmbclient
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 3.0.30
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Derrell Lipman
QA Contact: Samba QA Contact
Depends on:
Reported: 2008-07-02 16:55 UTC by Brian Sheehan
Modified: 2008-08-18 16:10 UTC (History)
0 users

See Also:

proposed patch (1.37 KB, patch)
2008-07-02 17:49 UTC, Brian Sheehan
no flags Details
patch with Kerberos (1.65 KB, patch)
2008-08-18 16:10 UTC, Brian Sheehan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Sheehan 2008-07-02 16:55:13 UTC
The reason for this is that clidfs.c opens a new connection after receiving a STATUS_PATH_NOT_COVERED error.  This new connection is opened through the do_connect function.  However the do_connect function uses credentials stored in global/static variables, not the ones of the prior connection.  So the username, workgroup end up being anonymous, and you are prompted for a password.  Being prompted for a password is not ideal if you are calling the lib programatically and not through an interactive client.  To set these global/static credential variables you have to call the functions cli_cm_set_credentials and set_global_myworkgroup.  Notice that smbclient does this (client/smbctool.c) in  in its get_auth_data_fn callback.  However if you use the libsmbclient library there is no way to access these functions (cli_cm_set_credentials and set_global_myworkgroup).

To fix this, a new function like smbc_set_credentials should be added to libsmbclient.  Then the user of the library could include the function call in the get_auth_data_fn callback.  

The function would look similar to what is in smbclient like this:

/* Set the credentials so DFS will work when following referrals.*/
smbc_set_credentials(char *workgroup, char *user, char *password)
        struct user_auth_info auth_info;

        pstrcpy(auth_info.username, user);
        pstrcpy(auth_info.password, password);
        auth_info.got_pass = True;

Comment 1 Brian Sheehan 2008-07-02 17:49:55 UTC
Created attachment 3378 [details]
proposed patch 

Here is a proposed patch for this issue.
Comment 2 Derrell Lipman 2008-07-08 19:49:02 UTC
Thanks, Brian.  I've taken your patch and modified it for use in the current development branch (v3-3-test).  Please let me know if anything doesn't work as expected.

Comment 3 Jeremy Allison 2008-07-08 19:57:52 UTC
Derrell, is this appropriate for 3.0.x or 3.2 ? Is looks like a simple extension to the API.
Comment 4 Derrell Lipman 2008-07-08 20:09:57 UTC
It could be, but it's very much an enhancement, not a bug fix, so I see it as appropriate only for the development branch.  I'm trying very hard (for both appropriateness of additions and to allow for my way-too-severe time limitations) to keep new code only in the development branch and limit my changes to the old branches only to significant bug fixes.

Comment 5 Brian Sheehan 2008-08-18 16:10:29 UTC
Created attachment 3489 [details]
patch with Kerberos

Added functionality to set the Kerberos details as well.