Issue #448


gofer logs "secret"

Added by mhrivnak almost 8 years ago. Updated almost 4 years ago.

Start date:
Due date:
Estimated time:
1. Low
2.4 Beta
Platform Release:
Sprint Candidate:
Pulp 2


This is based on data reported here:

Version-Release number of selected component (if applicable):

How reproducible:
pulp-automation, test case: tests.test_9_consumer_auth

Steps to Reproduce:
1. ensure authentication=True
2. create rpm repo
3. register consumer with rsa primary's pub key
4. launch consumer agent with another rsa
5. bind consumer agent to the repo distributor

Actual results:
"secret" is logged by gofer

Expected results:
"secret" should not be logged by gofer

Additional info:

  1. journalctl log entry
    gofer.transport.consumer:DEBUG: security.authentication, reason: None {"any": {"action": "bind", "consumer_id": "ConsumerAuthTest_consumer", "distributor_id": "zoo_distributor", "repo_id": "zoo", "task_id": "bb9c9824-33f7-4551-9a2a-d7e3d81ab4f6"}, "pam": null, "replyto": {"exchange": "pulp.agent.ConsumerAuthTest_consumer", "routing_key": "pulp.task"}, "routing": ["", "b0762bb4-a202-4358-984e-ab782fdef865"], "secret": "538f4df6bcb62b512ab4101a", "sn": "18dc9358-86c6-46d0-a8f8-1f70025aac0d", "status": "progress", "version": "0.5", "window": {}}

+ This bug was cloned from Bugzilla Bug #1105662 +

Actions #1

Updated by almost 8 years ago

Pulp passes the consumer DB object ID as the secret and is not used for authentication. Rather, it is used so that when a consumer is registered using the name of a previously unregistered consumer, the agent will not honor requests queued for the previous consumer. It leverages the gofer shared secret authentication mechanism as a matter of convenience only. So, logging the secret in this case represents no vulnerability to Pulp.

Long term gofer should mask out this filed when logging messages. Especially because 1.0+ logs to syslog which means that messages logged at DEBUG can now be viewed by non-root users.

To avoid confusion, Pulp /could/ pass the consumer DB object ID as part of the user defined data that is round-tripped on each request. The agent code could then explicitly add code to check the pass ID against the ID found in the consumer certificate and reject the request as needed. The downside is that we'd be writing code to avoid semantic confusion instead of using an existing mechanism. I think this would be a waste of time.

Pulp could also use the unique DB object ID when constructing the queue name (or gofer agent UUID). Like: pulp.agent.<_id>. This way, each registration would use a different queue and ignoring old requests would no longer be an issue. The pulp consumer certificate has this ID and it would be a straight forward change (though, would require another queue migration). A big problem with this approach is that candlepin certificates would not have this DB object ID so this would require additional changes to support this for SAT6. The need for agent queue reaping would be greater as this would potentially increase the rate at which we leak agent queues.

+ This comment was cloned from Bugzilla #1105662 comment 1 +

Actions #2

Updated by almost 8 years ago

This should be cloned to the "gofer" product.

+ This comment was cloned from Bugzilla #1105662 comment 2 +

Actions #3

Updated by bmbouter almost 4 years ago

  • Status changed from NEW to CLOSED - WONTFIX
Actions #4

Updated by bmbouter almost 4 years ago

  • Severity set to 1. Low

Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.

Actions #5

Updated by bmbouter almost 4 years ago

  • Tags Pulp 2 added

Added by daviddavis over 1 year ago

Revision a39b4473

Update cli tests to use cli.toml

fixes #448

Also available in: Atom PDF