Skip to content

Review locking/multi-threading implementation #36

Description

@michaelrsweet

According to @evilsocket, cups-browsed can be held up for an extended period of time:

The lock acquired here doesn't get unlocked until the IPP server has responded. A malicious IPP server can keep the connection going effectively remotely causing a DoS of the service.

I believe there's also a race condition because internally examine_discovered_printer_record then tries to unlock and relocks after a while.

We should review the locking and multi-threading implementation in cups-browsed to ensure we don't deadlock and don't wait indefinitely for a printer to respond. In particular, a short timeout (10 seconds?) should be set on any printer connection so that we minimize the chances of a misbehaving printer from preventing cups-browsed from setting up local print queues for legacy applications.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions