Description of problem: No access to a password read protected public file share Version-Release number of selected component (if applicable): gnome-user-share.i586 2.26.0-2.fc11 How reproducible: Always Steps to Reproduce: 0. On the very same computer from step 1 to 5: 1. Define a password for Gnome Personal File Sharing for "network public file sharing"/Password required/Always 2. Display current network resources 3. Double click on the requested remote resource xxxxx's public files on x.computer.xxx 4. Pop-up windows appears and requests password to be provided for "Please log in as the user guest" 5. Type in the password defined at step 1 Actual results: Error pop-up window saying "HTTP Error : Authorization Required" Expected results: Same result as the same procedure with Password required/Never option at step 1 instead of Always, ie creation at desktop level of a icon labeled "xxxxx public files on x.computer.xxx" Additional info: Updated out of the box Fedora 11. Accessing an unprotected share works fine.
I am seeing this too. Additional issues observed when password is 'Never': Mounting succeeds, but the window I open has a title of '/', which is confusing at best. Additional issues observed when password is 'When writing': Mounting succeeds, but when trying to create a file, I get an error dialog that says Error while creating file new file. There was an error creating the directory in dav+sd://mclasen%2527s%2520public%2520files%2520on%2520planemask._webdav._tcp.local/. Details: Authorization Required There's obviously multiple issues here...
This may acutally be a gvfs bug, ccing tbzatek
louy2k, could you please set the LogLevel to debug in: /usr/share/gnome-user-share/dav_user_2.2.conf and restart the HTTP sharing in gnome-user-share (untick/tick the http sharing in the properties will do). This should give us some debug, the files will be in: ~/.config/user-share/log You might want to remove that file before restarting the share, to be sure it's empty. I'm pretty sure this is a gvfs bug, and that it would work fine (or at least as well as it used to) from an F10 machine accessing the F11 gnome-user-share.
I have changed config from : cat /usr/share/gnome-user-share/dav_user_2.2.conf ServerRoot ${XDG_CONFIG_HOME}/user-share PidFile pid LockFile lock LogLevel crit #LogLevel info ErrorLog log to cat /usr/share/gnome-user-share/dav_user_2.2.conf ServerRoot ${XDG_CONFIG_HOME}/user-share PidFile pid LockFile lock Loglevel debug #LogLevel crit ##LogLevel info ErrorLog log + an untick/tick of the public file share option with Password Required set to always as well as password set. Following log file has been generated : c cat ~/.config/user-share/log [Tue May 12 19:36:43 2009] [notice] SELinux policy enabled; httpd running as context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [Tue May 12 19:36:43 2009] [notice] Digest: generating secret for digest authentication ... [Tue May 12 19:36:43 2009] [notice] Digest: done [Tue May 12 19:36:43 2009] [notice] Apache/2.2.11 (Unix) DAV/2 configured -- resuming normal operations [Tue May 12 19:36:43 2009] [info] Server built: Mar 17 2009 09:15:10 [Tue May 12 19:36:43 2009] [debug] prefork.c(1001): AcceptMutex: sysvsem (default: sysvsem)
The patch in http://bugzilla.gnome.org/show_bug.cgi?id=582373 helps a bit. It seems to fix the problem with 'Always'. The issue with 'When writing files' is still there.
Test packages are here: https://koji.fedoraproject.org/koji/buildinfo?buildID=101952
Sorry but Test Packages seem out of reach : Connection returns "ssl_error_handshake_failure_alert" after certificate has been accepted.
Does http://koji.fedoraproject.org/koji/buildinfo?buildID=101952 work better ?
The provided link works better. Thks I've installed all concerned packages and rebooted the system. here's the resulting log : ------------------ Ticking the share [Sat May 16 11:07:29 2009] [notice] SELinux policy enabled; httpd running as context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [Sat May 16 11:07:29 2009] [notice] Digest: generating secret for digest authentication ... [Sat May 16 11:07:29 2009] [notice] Digest: done [Sat May 16 11:07:29 2009] [notice] Apache/2.2.11 (Unix) DAV/2 configured -- resuming normal operations [Sat May 16 11:07:29 2009] [info] Server built: Mar 17 2009 09:15:10 [Sat May 16 11:07:29 2009] [debug] prefork.c(1001): AcceptMutex: sysvsem (default: sysvsem) -------------------- Try to access read protected share [Sat May 16 11:08:19 2009] [error] [client 192.168.0.12] Digest: user `guest' in realm `Please log in as the user guest' not found: / -------------------- END OF LOG Commment : The validation after password input falls back to a password input dialog box but without any password status option (remove immediately, keep until end of session, remember forever as they are shown at first connect attempt). Hope this helps.
(In reply to comment #5) > The patch in http://bugzilla.gnome.org/show_bug.cgi?id=582373 helps a bit. It > seems to fix the problem with 'Always'. The issue with 'When writing files' is > still there. Confirming, that patch fixes the issue with 'Always'. The issue with 'When writing files' is more complicated as we can present password prompt to the user only during mount operation. The soup "authenticate" callback for other situations is handled by passing the credentials we retrieved during the mount operation, no UI interaction there. (In reply to comment #9) > Commment : > The validation after password input falls back to a password input dialog box > but without any password status option (remove immediately, keep until end of > session, remember forever as they are shown at first connect attempt). Can you please clarify this? What do you mean by 'fall back' here? Does it show password prompt twice? Or you don't see the password save options?
Answering comment #10 Sorry 'fall back' isn't correct indeed. What I meant is that the password dialog box pops up again after first pwd input validation, but without password retaining policy options (password save options). gvfs updated to regular 1.2.3.2 packages. Firewall remains deactivated, connection from xxx session to xxx's shared public files Here's the log for feature activation and connection attempts : [Thu May 21 10:42:49 2009] [notice] SELinux policy enabled; httpd running as context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [Thu May 21 10:42:49 2009] [notice] Digest: generating secret for digest authentication ... [Thu May 21 10:42:49 2009] [notice] Digest: done [Thu May 21 10:42:49 2009] [notice] Apache/2.2.11 (Unix) DAV/2 configured -- resuming normal operations [Thu May 21 10:42:49 2009] [info] Server built: Mar 17 2009 09:15:10 [Thu May 21 10:42:49 2009] [debug] prefork.c(1001): AcceptMutex: sysvsem (default: sysvsem) [Thu May 21 11:09:35 2009] [error] [client 192.168.0.12] Digest: user `guest' in realm `Please log in as the user guest' not found: / Cancellation brings a pop-up saying "Impossible to mount ...."/"HTTP Error : Cancelled" SELinux policy error/warning hasn't been commented yet ... Couldn't it be a source of problem ?
(In reply to comment #11) > What I meant is that the password dialog box pops up again after first pwd > input validation, but without password retaining policy options (password save > options). weird... can you please run `GVFS_DEBUG=1 /usr/libexec/gvfsd -r`, go through your usual mount operation and attach the output here? > [Thu May 21 11:09:35 2009] [error] [client 192.168.0.12] Digest: user `guest' > in realm `Please log in as the user guest' not found: / I don't like this message. Can you please disable sharing, rm -rf ~/.config/user-share and set up sharing again (including password)? The ~/.config/user-share/passwd should look like "guest:Please log in as the user guest:908d85a6f2b7d74f0dba259b3a7c148b" > SELinux policy error/warning hasn't been commented yet ... Couldn't it be a > source of problem ? The SELinux message you posted is correct. Are there any denials in dmesg? Does `sealert -b` show any suspicious denials related to gnome-user-share? Does `setenforce 0` help in this case?
Please find the requested results : GVFS_DEBUG=1 /usr/libexec/gvfsd -r Added new job source 0x8c60c48 (GVfsBackendDav) Queued new job 0x8c6a800 (GVfsJobMount) + mount + soup_authenticate_interactive (first auth) - soup_authenticate + soup_authenticate_interactive (retrying) - soup_authenticate send_reply, failed: 1 cat '/home/luc/.config/user-share/passwd' guest:Veuillez vous connecter en tant qu'utilisateur invité:8782752615992b11a150323301bb750a dmesg.log in following attachment.
Created attachment 345094 [details] dmesg output No problem reported IMO.
Forgot to say "sealert -b" is empty
Thanks for the outputs, so far it all looks correct. (In reply to comment #13) > cat '/home/luc/.config/user-share/passwd' > guest:Veuillez vous connecter en tant qu'utilisateur > invité:8782752615992b11a150323301bb750a Did you try to delete the settings and set it up again? No idea what else can be broken here...
Yes I once again did. No change, as far as I can notice. Trying to sum up the issue I came to list 3 relevant issues IMHO : 1) The pop up dialog to connect to the ressource displays the following quoted sentence : "Saisissez le mot de passe pour Please log in as the user guest" This prompt is a sentence that combines localized language, i.e. french and "system language", i.e. english. Intriguing ... 2) Moreover the ~/.config/user-share/passwd contains localized sentence ("Veuillez vous connecter en tant qu'utilisateur invité") highly possible to be the french translation of the system part of the prompt previously mentioned in 1) 3) To end with this subject the log file sums up the authentication failure as follows : "user `guest' in realm `Please log in as the user guest' not found: /" Now we learn that the name of the realm the user 'guest' is expected to be acknowledged by is equivalent to the system part of the sentence commented in 1). I remember you saying in comment #12 you didn't like that sentence. => The localized sentence contained in ~/.config/user-share/passwd is never displayed on the screen during the authentication process, Intriguing ... => This is my two cents comment of course, but as you seem to have no issue on your fedora system which I suppose to be in english, couldn't it be a issue due to localization causing problems on my side ?
You're right, I'm finally able to reproduce and debug this issue. Localization is the problem here. I'll keep you posted about the progress.
Thks for reply, sorry for cerebral latence, I should have figured out earlier I guess. Wishing you the best & because of the RC to come, hoping you don't to much of a pressure, if any. ;)
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've opened an upstream bug, describing my findings. My idea proved not to be working, expecting a little stupid mistake there. http://bugzilla.gnome.org/show_bug.cgi?id=586755
*** Bug 505060 has been marked as a duplicate of this bug. ***
gnome-user-share-2.26.0-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gnome-user-share-2.26.0-3.fc11
gnome-user-share-2.26.0-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
I am having the issue described above running gnome-user-share-2.28.2-1.fc12 with a german-localized user environment.
Loglevel debug revealed: $ grep error .config/user-share/log [Sat Feb 20 14:53:46 2010] [error] [client 192.168.1.2] Digest: user `guest' in realm `Bitte melden Sie sich als Gastbenutzer an' not found: / $ cat .config/user-share/passwd guest:Please log in as the user guest:0f00a00abf0b685d9dc948fd56f62878
(In reply to comment #26) > [Sat Feb 20 14:53:46 2010] [error] [client 192.168.1.2] Digest: user `guest' in > realm `Bitte melden Sie sich als Gastbenutzer an' not found: / You're right, this shouldn't be localized. Fixed upstream, will package it to F12 and F13 soon. http://git.gnome.org/browse/gnome-user-share/commit/?id=1a2aff08c16c87fcae10563acd9485624a5e262d
gnome-user-share-2.28.1-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gnome-user-share-2.28.1-5.fc13
gnome-user-share-2.28.2-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gnome-user-share-2.28.2-2.fc12
gnome-user-share-2.28.2-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.