Re: crypt_r()?

[Jason Thorpe <thorpej%me.com@localhost>]

> On Feb 15, 2022, at 3:30 PM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> 
> Am Wed, Feb 16, 2022 at 12:04:16AM +0100 schrieb Niclas Rosenvik:
>> do you mean that the interface should be 
>> crypt_r(const char *key, const char setting, char * storage, size_t
>> *storage_len)
>> where storage can be set to NULL to return the needed storage size in
>> storage_len?
> 
> No. There are two sensible interface contracts here:
> 
> (1) Verification only, which takes the password and the expected hash
> and returns a bool. No separate settings necessary as the hash already
> contains all the necessary parameters.
> 
> (2) Hashing password, which takes the password and the settings and
> returns an allocated string with the resulting hash. This is essentially
> the same interface as crypt(3), but the caller is responsible for
> free(3) the return value. Given that the goal of the crypt(3) interface
> is to be slow, optimizing a memory allocation away saves nothing, except
> making a more complicated interface.

While we’re on the topic of “what we’d like the interfaces to do”…

There really should be a function that takes a user name or ID and a cleartext password string, and IPCs to another (trusted system) process to do the verification, so that programs that want to verify passwords don’t need root privileges.  Same for changing passwords.

Then there’s no need for any of this crypt(3) tomfoolery.

-- thorpej