SSSD / sssd

#3391 sss_override doesn't work with files provider
Closed: Fixed Opened by fidencio.

Closed: Fixed
Reopen Issue

While testing a PR related to sss_override, I've realized that sss_override user-add doesn't work when using files provider:

[vagrant@client1 x86_64]$ getent passwd john
john:x:1002:1002::/home/john:/bin/bash
[vagrant@client1 x86_64]$ sudo sss_override user-add john -u 1001 -g 1001
SSSD needs to be restarted for the changes to take effect.
[vagrant@client1 x86_64]$ sudo systemctl restart sssd
[vagrant@client1 x86_64]$ getent passwd john
john:x:1002:1002::/home/john:/bin/bash

sssd.conf:

[sssd]
services = nss, sudo, pam, ssh, ifp
domains = files
[domain/files]
id_provider = files

Much better would be to provide an integration tests. We already have cwrap integration tests for sss_override and files provider.

I guess the integration test must be part of the PR?

Or are you suggesting to open the issue with the integration test?
Edited by fidencio

The good bug description contains all required and deterministic steps to reproduce. And the best steps to reproduce is to write a test which is obviously failing due to bug.

It doesn't make sense to ask reporters to write an integration test, at all.

While I understand your reasoning and I do agree that having an integration test is the best case for us (and must be mandatory in the PR solving this issue), expecting whoever hits a bug and files an issue to spend time on writing integration tests is a little bit too much, sorry.

To make you happier, yes, I can provide the tests, but when I have time to do so.

And I sincerely prefer a reported issue with confs/steps to reproduce even without integration tests than wait till someone is able to provide the integration tests and just open the issue after that.

It doesn't make sense to ask reporters to write an integration test, at all.

You are not ordinary reporter. You are sssd developer.

And I sincerely prefer a reported issue with confs/steps to reproduce even without integration tests than wait till someone is able to provide the integration tests and just open the issue after that.

Usually bug reports miss a lot of important things. (e.g. log files) I cannot see any log files here. Or provided bug reports are not deterministic. People also tend to forget details after a time.

BTW this bug reports is not deterministic. Because "getent passwd john" does not return anything on my machine. I would probably be able to reproduce it. But on the other hand it would take just 10 minutes to write a test. And test must be written anyway. So the ideal is to write a test with fresh memories about reproducer.

It doesn't make sense to ask reporters to write an integration test, at all.

You are not ordinary reporter. You are sssd developer.

And I sincerely prefer a reported issue with confs/steps to reproduce even without integration tests than wait till someone is able to provide the integration tests and just open the issue after that.

Usually bug reports miss a lot of important things. (e.g. log files) I cannot see any log files here. Or provided bug reports are not deterministic. People also tend to forget details after a time.
BTW this bug reports is not deterministic. Because "getent passwd john" does not return anything on my machine.

Okay, I'll improve the bug report then.

I would probably be able to reproduce it. But on the other hand it would take just 10 minutes to write a test. And test must be written anyway. So the ideal is to write a test with fresh memories about reproducer.

While it may take you 10 minutes to write a test, it doesn't take me 10 minutes to do the same thing and "sorry" about that is the only thing I can say here.

While it may take you 10 minutes to write a test, it doesn't take me 10 minutes to do the same thing and "sorry" about that is the only thing I can say here.

Because you are not used to write tests. Which has to change based on team goals for next year. And the best thing is to practice with simple tasks. This is an ideal opportunity.

As suggested by @lslebodn, there's a PR with the integration test for this issue: https://github.com/SSSD/sssd/pull/265

When looking at this, please consider if the bug is related to the files provider only -- if yes, then we should perhaps just improve the files provider detection in sss_override.

The primary concern when looking at this bug should be whether it affects other domains.

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.15.4

Metadata Update from @sbose:
- Issue assigned to sbose
  • master:
  • 1b3ca692bb8f93b87703447904bda80d45a75835
  • 0c5b97812f20b57b93c10496fed34ea221fbcca8
  • 9cca5bff0b934e97e100be53ea08dc6919446ff0

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue set to the milestone: SSSD 1.15.3 (was: SSSD 1.15.4)
- Issue status updated to: Closed (was: Open)

tests: b294f9f082c97f0c6ef16739e19826a16375444e

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4418

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.