#3368 IFP: Return an error, not a default value for some attributes should not be read

Created 3 months ago by jhrozek
Modified 3 months ago

The IFP interface was designed from the start to return /a value/ always, to make life easier for clients. Normally we return a default value for the type - "" for string, 0 for numbers etc.

But for some values, crashing the client application might actually be easier. One notable example is requesting an UID or GID in a non-POSIX domain. Returning 0 really makes little sense here, we should rather throw an error and let the client deal with it.

3 months ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Future releases (no date set yet)

Login to comment on this ticket.

cancel