suidubins should be suidusbins, since these binaries are installed
${prefix}/sbin. This historically hasn't broken the build because
chmod of newgidmap/newuidmap succeeds, causing make to think the command
succeeded. Configuring shadow with --with-fcaps removes these final two
entries and exposes the chmod failure to make.
Some distros don't care about the split between /bin, /sbin, /usr/bin,
and /usr/sbin, so let them easily stuff binaries wherever they want.
This also fixes a problem during installation where-in a loop of 'chmod
4755' calls will mostly fail. However, because the last two succeed
(newuidmap/newgidmap), make considers the command to be a success.
Somewhat not-amusingly, configuring shadow with --with-fcaps will cause
installation to fail because the final chmod call is now a failing one.
Fix formatting of login.defs comments. Variables are preceeded by "#"
without space, comments are preceeded by "# ". It makes the file machine
parseable again.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
A configure error occurs when /bin/sh -> dash:
checking for is_selinux_enabled in -lselinux... yes
checking for semanage_connect in -lsemanage... yes
configure: 16322: test: yesyes: unexpected operator
Use "=" instead of "==" since dash doesn't support this operator.
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
new switch added to useradd command, --btrfs-subvolume-home. When
specified *and* the filesystem is detected as btrfs, it will create a
subvolume for user's home instead of a plain directory. This is done via
`btrfs subvolume` command. Specifying the new switch while trying to
create home on non-btrfs will result in an error.
userdel -r will handle and remove this subvolume transparently via
`btrfs subvolume` command. Previosuly this failed as you can't rmdir a
subvolume.
usermod, when moving user's home across devices, will detect if the home
is a subvolume and issue an error messages instead of copying it. Moving
user's home (as subvolume) on same btrfs works transparently.
As the lockfiles have PID in the name, there can be no conflict
in the name with other process, so there is no point in using
O_EXCL and it only can fail if there is a stale lockfile from
previous execution that crashed for some reason.
The implementation of prefix option dropped the use of lckpwdf().
However that is incorrect as other tools manipulating the shadow passwords
such as PAM use lckpwdf() and do not know anything about the
shadow's own locking mechanism.
This reverts the implementation to use lckpwdf() if prefix option
is not used.
From <https://github.com/shadow-maint/shadow/pull/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
- translated by Jean-Philippe MENGUAL
- proofread by the debian-l10n-french mailing list contributors
Signed-off-by: Alban VIDAL <alban.vidal@zordhak.fr>
