Make the sp_lstchg shadow field reproducible (re. #71)

[lamby]

From #71:

The third field in the /etc/shadow file (sp_lstchg) contains the date of
the last password change expressed as the number of days since Jan 1, 1970.
As this is a relative time, creating a user today will result in:

username:17238:0:99999:7:::
whilst creating the same user tomorrow will result in:

username:17239:0:99999:7:::
This has an impact for the Reproducible Builds[0] project where we aim to
be independent of as many elements the build environment as possible,
including the current date.

This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
environment variable (instead of Jan 1, 1970) if valid.

This updated PR adds some missing calls to gettime (). This was originally
filed by Johannes Schauer in Debian as #917773 [2].

[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
[2] https://bugs.debian.org/917773

[hallyn]

Is there any security concern here? It seems like the only possible problem would be if a user with no shadow entry called passwd with a future date for SOURCE_DATE_EPOCH.

[lamby]

What would be the hypothetical attack there, just out of interest?

(re. security, there are other related discussions, possibly from yourself, on this area in the above links IIRC)

[hallyn]

The only attack I can imagine is delaying/preventing password aging. But I'm often not very imgaintaive...

[lamby]

Nor I, alas. :) I don't believe there is an issue, obviously...

[t8m]

Actually it would be a security issue if user without preexisting shadow entry could prevent password ageing on password change. Although the issue would be fairly low impact one. I'd suggest using secure_getenv() instead of normal getenv() in gettime().

[lamby]

Good idea re secure_getenv - pushed.

[hallyn]

Stupid q - is there any libc which would not provide secure_getenv()? Actually the manpage says it's glibc-specific. Should a dummy helper be added if it's not defined?

[lamby]

Sorry for dropping this over the new year. Any update from you folks? :)

[hallyn]

Any update from you folks? :)

Yes, I'd like discussion about my question - is there a libc we need to worry about which would not provide secure_getenv()?

[lamby]

is there a libc we need to worry about which would not provide secure_getenv()?

Busybox?

[lamby]

Updated to support the case where secure_getenv is not supported. Ready to merge. :)

[hallyn]

Hi,

I'm going to merge this as is, but I have a feeling that it would be better to emulate secure_getenv() if libc doesn't provide it.