maindavfs2 - Support: sr #107226, Reassigned to another tracker...

 
 

sr #107226: Reassigned to another tracker [was: Experimental username option fails with SIGABRT]

Submitter:  Peter Fern <pdf>
Submitted:  Thu 21 Jan 2010 03:25:19 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  In Progress
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 21 Jan 2010 06:46:44 PM UTC, comment #2: 

THIS ITEM WAS REASSIGNED TO BUG #28706


Please, do not post any new comments to this item.

- <_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 03:25:19 AM UTC, original submission:  

THIS ITEM WAS REASSIGNED TO BUG #28706
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:
   

No files currently attached

 

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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-01-21 _71007 Reassign Itemdavfs2, sr #107226 davfs2, bug #28706
    2010-01-21 _71007 StatusNone In Progress
        Assigned toNone _71007
    2010-01-21 pdf Attached File- Added davfs2.trace, #19520

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code