Bug 10551 - Daemon infinite loop when no matched user in secrets
Summary: Daemon infinite loop when no matched user in secrets
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: x64 Linux
: P5 major (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-13 10:41 UTC by Ryan Finnie
Modified: 2014-04-13 21:14 UTC (History)
0 users

See Also:


Attachments
Strace output of infinite loop (36.12 KB, application/octet-stream)
2014-04-13 10:41 UTC, Ryan Finnie
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Finnie 2014-04-13 10:41:22 UTC
Created attachment 9850 [details]
Strace output of infinite loop

Hello.  Given a test module:

[test-module]
  path = /tmp
  auth users = *
  secrets file = /tmp/rsyncd.secrets

and secrets file:

gooduser:goodpass

and running a daemon, good user / good password and good user / bad password work as expected:

$ RSYNC_PASSWORD=goodpass rsync rsync://gooduser@host/test-module/
drwxrwxrwt         12,288 2014/04/13 03:31:34 .

$ RSYNC_PASSWORD=badpass rsync rsync://gooduser@host/test-module/
@ERROR: auth failed on module test-module
rsync error: error starting client-server protocol (code 5) at main.c(1653) [Receiver=3.1.0]

But specifying a nonexistent username puts the daemon into an infinite loop.

$ RSYNC_PASSWORD=badpass rsync rsync://baduser@host/test-module/

A partial strace is attached, but basically it reads to the end of rsync.d.secrets, then loops:

27953 select(5, [4], NULL, [4], {60, 0}) = 1 (in [4], left {59, 999999})
27953 read(4, "", 1)                    = 0

The parent process remains open for other connections, but the child process goes into a CPU spin.

I've done a git bisect, and the problem appears to have been introduced with commit 5ebe9a46d7f3c846a6d665cb8c6ab8b79508a6df (Add @group auth and overrides to "auth user" daemon config.).
Comment 1 Wayne Davison 2014-04-13 21:14:04 UTC
I've committed a fix for this into git for release in 3.1.1.  Thanks for the report!