Skip to content

Review locking/multi-threading implementation #36

@michaelrsweet

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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions