bugdavfs2 - Bugs: bug #28706, Experimental username option fails...

 
 

bug #28706: Experimental username option fails with SIGABRT

Submitter:  Peter Fern <pdf>
Submitted:  Thu 21 Jan 2010 06:46:44 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 21 Jan 2010 07:19:55 PM UTC, comment #3: 

Addition:
SIGABRT is caused by mount.davfs itself. The second attempt to read the password will fail as the pipe is probably already closed. As I see no way to resume from a failure to read the password, mount.davfs calls abort.

Werner

- <_71007>
Thu 21 Jan 2010 06:46:44 PM UTC, comment #2: 

This item has been reassigned from the project davfs2 support tracker to your tracker.

The original report is still available at support #107226

Following are the information included in the original report:

[field #0]                  Item ID: 107226
[field #1]                 Group ID: 10199
[field #2]              Open/Closed: Open
[field #3]                 Severity: 3 - Normal
[field #4]                  Privacy: Public
[field #8]                         : Unknown support Field Display Type
[field #9]                 Category: None
[field #10]             Submitted by: pdf
[field #11]              Assigned to: wbaumann
[field #12]             Submitted on: Do 21 Jan 2010 03:25:19 GMT
[field #13]                  Summary: Experimental username option fails with SIGABRT
[field #14]      Original Submission: Attempting to mount using the experimental 'username' option results in a failure with SIGABRT, as shown in the attached strace output.

I've manually tried piping the password in (as in the trace), and typing it in when prompted (same result), however I was attempting to use this with pam_mount, so I'll give you some background as to why I hope this option will work, and not go away:

We have a DMS that allows access to documents via WebDAV.  This greatly simplifies user interaction with the DMS, however we need to have each user log in with their username.  On a shared X server, people log in with their LDAP auth details, and our ideal action at this point would be for users to have their view of the document repository automatically mounted to a directory in their homedir.

Obviously having their credentials stored on the system is less than optimal, since it means re-syncing their creds whenever they're changed somewhere else in the architecture, not to mention having to add fstab entries every time a user is added/removed.  Also, all users mount the same WebDAV URL (which will also cause problems for fstab), but receive different views based on their login.
[field #16]               Item Group: None
[field #17]                   Status: In Progress
[field #18]        Component Version: None
[field #19]         Operating System: GNU/Linux
[field #20]          Reproducibility: None
[field #21]               Size (loc): None
[field #22]            Fixed Release: None
[field #23]          Planned Release: None
[field #24]                   Effort: 0.00
[field #28]                 Priority: 5 - Normal
[field #31]         Percent Complete: 0%
[field #33]                  Release: None
[field #58]     Custom Select Box #1: None
[field #59]     Custom Select Box #2: None
[field #60]     Custom Select Box #3: None
[field #61]     Custom Select Box #4: None
[field #62]     Custom Select Box #5: None
[field #63]     Custom Select Box #6: None
[field #64]     Custom Select Box #7: None
[field #65]     Custom Select Box #8: None
[field #66]     Custom Select Box #9: None
[field #67]    Custom Select Box #10: None

- <_71007>
Thu 21 Jan 2010 06:44:45 PM UTC, comment #1: 

Hello Peter,

this looks like one of my copy-and-paste-errors.

In the sources, file mount_davfs.c, function parse_secrets, around line 1153:


    if (args->cl_username) {
        if (args->username)
            free(args->username);
        args->username = args->cl_username;
        args->cl_username = NULL;
        if (args->password)
            free(args->password);
        args->password = NULL;
        args->p_passwd = user_input(_("Password: ")); /* assignment to wrong variable */
    }


The password read by 'user_input' is assigned to the wrong variable. So mount.davfs tries again, writing "Please enter .." and gets SIGABRT.

Please change the line like this:


    if (args->cl_username) {
        if (args->username)
            free(args->username);
        args->username = args->cl_username;
        args->cl_username = NULL;
        if (args->password)
            free(args->password);
        args->password = NULL;
        args->password = user_input(_("Password: "));
    }


According to strace mount.davfs read the password successfully in the first attempt. With this fix it will not try it again.
Though I don't know why writing to stdout causes SIGABRT, I hope this will fix the problem.

I will move the thread from the support tracker to the bug tracker and fix the bug in CVS.

Cheers
Werner

P.S.: multiple lines in fstab with the same URL should not cause problems as long as the mount point is different.

- <_71007>
Thu 21 Jan 2010 06:46:44 PM UTC, original submission:  

Attempting to mount using the experimental 'username' option results in a failure with SIGABRT, as shown in the attached strace output.

I've manually tried piping the password in (as in the trace), and typing it in when prompted (same result), however I was attempting to use this with pam_mount, so I'll give you some background as to why I hope this option will work, and not go away:

We have a DMS that allows access to documents via WebDAV.  This greatly simplifies user interaction with the DMS, however we need to have each user log in with their username.  On a shared X server, people log in with their LDAP auth details, and our ideal action at this point would be for users to have their view of the document repository automatically mounted to a directory in their homedir.

Obviously having their credentials stored on the system is less than optimal, since it means re-syncing their creds whenever they're changed somewhere else in the architecture, not to mention having to add fstab entries every time a user is added/removed.  Also, all users mount the same WebDAV URL (which will also cause problems for fstab), but receive different views based on their login.

Peter Fern <pdf>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #19520:  davfs2.trace added by pdf (29KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by pdf (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-05-02 _71007 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2010-01-21 _71007 StatusNone Ready For Test
        Assigned toNone _71007
    2010-01-21 _71007 Reassign itemdavfs2, sr #107226 davfs2, bug #28706

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code