shadow-maint/shadow

Upstream shadow tree

shadow's Issues

useradd: segmentation fault

Arch Linux:

• linux 4.18.4 x86_64
• shadow 4.6
• glibc 2.28

Running:

useradd -Ds /bin/sh

yields under gdb:

Program received signal SIGSEGV, Segmentation fault.
#0  0x00007ffff76503c3 in __gen_tempname (tmpl=0x55555556ce51 "/etc/default/nuaddvXXXXX", suffixlen=<optimized out>, flags=<optimized out>, kind=0) at tempname.c:246
#1  0x0000555555559ccd in set_defaults () at useradd.c:542
#2  0x000055555555e454 in main (argc=3, argv=0x7fffffffec48) at useradd.c:2256

In useradd.c:

#define NEW_USER_FILE "/etc/default/nuaddXXXXXX"

static int set_defaults (void)
{
	char* new_file = NEW_USER_FILE;

	if(prefix[0]) {
		// new_file allocated with malloc
	}

	ofd = mkstemp (new_file);
}

when the prefix is empty, mkstemp is called with a const char*. According to mkstemp manual:

SYNOPSIS
  int mkstemp(char *template);

DESCRIPTION
  Since it will be modified, `template` must not be a string constant,
  but should be declared as a character array.

Temporary workaround:

useradd -Ds /bin/sh -P //

Potentially unsafe use of getlogin CVE-2016-6251

Reported to SuSe bug tracker with proposed fix.
https://bugzilla.suse.com/show_bug.cgi?id=979282

There is also a discussion on oss-security and pkg-shadow-devel:
http://seclists.org/oss-sec/2016/q3/120
https://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2016-July/011017.html

unlink is not executed on /etc/shadow.lock

Running any user/password manipulating program from shadow package leaves /etc/shadow.lock file, which prevents further actions on user management.

Based on strace output it is visible that unlink is executed on all /etc/{gshadow,group,passwd}.lock
except /etc/shadow.lock when running for example useradd.

https://issues.openmandriva.org/show_bug.cgi?id=1375

conditional man pages

The upstream tarball ships with pre-made man pages.
However the content of the man pages is dependent on compile options.
For example: https://github.com/shadow-maint/shadow/blob/master/man/login.defs.d/CHFN_AUTH.xml#L31

So in case shadow is compiled with --with-libpam, man login.defs will not include the entry about CHFN_AUTH.

Some distributions however just use the pre-made man pages, meaning the man pages don't fit their installation exactly.

To use the right one it is necessary to compile with --enable-man and also have the following:

• xsltproc
• docbook 4
• docbook stylesheets
• xml2po

If one of the first three is not present at build time, it will silently switch --enable-man off.

So this bug report is about discussing whether shipping pre-made man pages is a good idea because they depend on conditions. And if yes, whether we should note somewhere that they are conditional so distributions are aware of it an choose to build them themselves.
Shipping them but adding a note has the benefits of not adding more build requirements as a must.

Upload more release tarballs

Over in the OpenEmbedded we use Debian's shadow package, would it be possible for you to upload more of the official tarballs from the Debian mirrors to github? Specifically 4.2.1 would be great. :)

Incorrect integer handling CVE-2016-6252

Reported to SuSe bug tracker with proposed fix.
https://bugzilla.suse.com/show_bug.cgi?id=979282

Consider consulting USER/LOGNAME in get_my_pwent?

To distinguish between multiple users with shared user IDs, get_my_pwent currently calls getlogin, and uses the result if it matches the current user ID. Unfortunately, getlogin has a number of cases where it can return the wrong value or no value, such as when running under sudo, running without a controlling terminal, or when the username is longer than a system-specified limit. Much more reliable, in my experience, (but by no means trustworthy) is consulting the USER and/or LOGNAME environment variables, which tend to be set correctly in all of these cases.

Given that getlogin() isn't trustworthy, either, and get_my_pwent already checks to make sure the returned username matches the current user ID, I think this would make it work in more cases without much of a drawback. (Though there of course may be drawbacks I'm not thinking of.) Would others agree? I'd be happy to put together a small pull request for this.

compilation error in su.c

Edit: sorry, double post.

Prefix "Not copying any file from skel directory into it."

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894996

We also see
Not copying any file from skel directory into it.

If this is from useradd, then I would prefix it
useradd: Not copying any file from skel directory into it.

Missing 4.2.1 tag

The 4.2 tags are missing on the repo, which makes it hard to compile an rpm.

It looks to me like it should point to 8b4e03b99440f35550118f0d102b3ffc1622586f

[pwck] Segmentation fault when executing on a nonexistent passwd file

Hello,

executing pwck on a nonexistent passwd file results in a segmentation fault:

root@lambda ~# pwck /tmp/nonexistent
fish: “pwck /tmp/nonexistent” terminated by signal SIGSEGV (Address boundary error)

This bug is present in the version of the tool currently shipped in Arch Linux,

root@lambda ~# uname -a
Linux lambda 4.15.2-2-ARCH #1 SMP PREEMPT Thu Feb 8 18:54:52 UTC 2018 x86_64 GNU/Linux
root@lambda ~# pacman -Qi shadow
Name            : shadow
Version         : 4.5-4
. . .

but was probably already observed on 2017-04-10 as mentioned in this post from the Arch Linux Forums. Moreover, I compiled (--without-selinux) the code from this repository and verified the bug is present in both the tag 4.5 and the latest commit.

A brief debugging session revealed that the segmentation fault happens in commonio_close() and is caused by a call to fclose() with a null pointer argument. Backtrace:

[#0] 0x7ffff7a8dc64 → Name: fclose@@GLIBC_2.2.5()
[#1] 0x555555559940 → Name: commonio_close.part()
[#2] 0x55555555ab26 → Name: commonio_unlock()
[#3] 0x55555555707f → Name: main()

Relevant snippets from lib/commonio.c (tag 4.5):

int commonio_close (struct commonio_db *db)
    /*@requires notnull db->fp@*/
{
    . . .
    if (!db->changed || db->readonly) {
        (void) fclose (db->fp);
        . . .
    }
    . . .
}

int commonio_unlock (struct commonio_db *db)
{
    . . .
    if (db->isopen) {
        db->readonly = true;
        if (commonio_close (db) == 0) {
            . . .
        }
    }
    . . .
}

int commonio_open (struct commonio_db *db, int mode)
{
    . . .
    /*
     * If O_CREAT was specified and the file didn't exist, it will be
     * created by commonio_close().  We have no entries to read yet.  --marekm
     */
    if (NULL == db->fp) {
        if (((flags & O_CREAT) != 0) && (ENOENT == errno)) {
            db->isopen = true;
            return 1;
        }
        return 0;
    }
    . . .
}

I have not investigated the issue further. Note that executing pwck in read-only mode does not trigger the bug:

root@lambda ~# pwck -r /tmp/nonexistent
pwck: cannot open /tmp/nonexistent

group/user add --root option when target arch is different than host

Hi,

It is a long time I'm missing this feature: being able to create user/group when cross compiling.
Currently the --root option is doing a chroot.
I would like to add a new option (---prefix?) that will just prefix the path to shadow files instead of using the hardcoded /etc/group etc paths.
In this case we'll be able to create all the users/group before generating the embedded firmware.
Of course, it may imply some limitations (pam authentification will still use the host accounts for example... same for ldap?)
But before going this route, I would like to understand if there is any reason why was it never done?
Should I take core of some specific points too? (maybe some advanced features that I should be aware of?)

Thank you

"no changes" is not an error, it should not be output to stderr

If a command such as: /usr/sbin/usermod -s /sbin/nologin sysaccount has no effect then it outputs
"usermod: no changes" to stderr and returns with an exit code of 0.
Because it is not an error but rather an informational message, this message should rather be output to stdout.

While it seems like a meaningless change, I have a use case where a script runs that command upon upgrade to ensure the system user's shell is set correctly.
However, to keep the upgrade output terse I do not wish to show the message "usermod: no changes" but would still like to report on actual errors (sent to stdout). Currently the only option I have to achieve that is to involve capturing the exit code and only showing error output based on its returned value.

newusers xx.file bug

on debian jessie
passwd 1:4.2-3+deb8u3 armel

works correctly if file contains just one line, but it fails when it
has multiple entries

newusers test.a
*** Error in newusers: free(): invalid next size (fast): 0x80d029f8 ***
Aborted

cat test.a haozi2:x:1002:1002::/home/haozi2:/bin/sh haozi3:x:1003:1003::/home/haozi3:/bin/sh

The bug is know also here

https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1266675
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756630

su: check whether waitpid() return value is equal to pid_child

When su runs as pid 1 (happened to me in Docker), it can get adopted children.
If such child exits, it makes su exit prematurely with its retcode.
It would be great to simply loop here https://github.com/shadow-maint/shadow/blob/master/src/su.c#L357 if pid != -1 && pid != pid_child.

groupmod can exit with an unknown error code of 1

Currently groupmod has 3 exit points that share the undefined and undocumented exit code of 1.
The meaning for each of these is different, 2 related to PAM, one the cleanup service.

I'm raising a PR that explicitly defines 3 new error codes for these cases, and documents the fact that one of these drops the actual pam error into syslog with a facility code of "groupmod"

Missing .asc file for 4.6 release

Hi there,
maybe you still plan on doing this, but here is a short reminder. .asc file is missing in GH downloads for 4.6 release ;)

Give the path of the directory you are talking about

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894996

We see:
useradd: warning: the home directory already exists.

The problem is this might be in a forest of other messages,
so please say what (user's) directory you are talking about.
Give the exact path.

Expired password changed with `usermod -p` is not set to unexpired

Hi,

The security policy in ClearLinux creates images where the root password is always set to be expired. This forces the first-time user to immediately change the root password.

However, we additionally need to allow programs such as cloud-init to set the password in a secure way through e.g. usermod -p /encrypted pass/. This changes the password properly, but never un-expires the password, causing sudo etc. to fail on first use (even with NOPASSWD in sudoers.d).

I'd like to be able to have usermod -p $hash also clear the expiry flag in shadow automatically. It seems logical that an expired password being changed (through whichever password change method there is) that the "password is expired" flag should be cleared as well.

Right now our users are overwriting the shadow file, which is a less desirable way of dealing with this. If this would be done automatically or with an optional flag, it would solve the problem for us.

I also couldn't find other methods to clear the flag.

groups command shows its output twice

I'm using =sys-apps/shadow-4.5 on a Gentoo Linux system.

I noticed a strange behavior by the groups command:

$ groups fturco
audio cdrom floppy input lp lpadmin plugdev portage scanner usb users video wheel audio cdrom floppy input lp lpadmin plugdev portage scanner usb users video wheel fturco
$ groups
lp wheel floppy audio cdrom video usb users scanner plugdev lpadmin input portage fturco

Basically if I specify my username all groups except one are repeated twice.

$ emerge -pv shadow

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/shadow-4.5::gentoo  USE="acl nls -audit -cracklib -pam (-selinux) -skey -xattr" LINGUAS="-cs -da -de -es -fi -fr -hu -id -it -ja -ko -pl -pt_BR -ru -sv -tr -zh_CN -zh_TW" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

pwconv: keeps some lines that should be deleted from /etc/shadow

Copied from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801981

Hi, I observed a strange behaviour when pwconv should delete several
lines from /etc/shadow.

Here is how to reproduce it:

Starting from a standard installation, add some users, for example:

root@debian:~# for i in $(seq 10); do adduser --no-create-home --disabled-password --gecos '' test$i; done

As expected, they appear in /etc/passwd and /etc/shadow.
Now delete them from /etc/passwd, e.g using vipw.
They are still in /etc/shadow, pwconv should be able to fix that.
However, every other entry will be kept:

  root@debian:~# pwconv
  root@debian:~# grep test /etc/shadow
  test2:*:16724:0:99999:7:::
  test4:*:16724:0:99999:7:::
  test6:*:16724:0:99999:7:::
  test8:*:16724:0:99999:7:::
  test10:*:16724:0:99999:7:::

Even more strange, after a second pwconv only test8 remains.

The same thing happens with grpconv.

Allow dots (`.`) in user/group names

Is there a technical reason why dots (.) are not allowed in user/group names?

And if not, would a PR to allow them be accepted? It seems like a simple enough change to is_valid_name in libmisc/chkname.c.

broken code in `src/Makefile.am`

The code in question is

shadow/src/Makefile.am

Line 58 in a3bf32f

suidubins += chage chgpasswd chpasswd groupadd groupdel groupmod newusers useradd userdel usermod

1. chage shouldn't be there as it is already specified here

   shadow/src/Makefile.am

   Line 56 in a3bf32f

   suidubins = chage chfn chsh expiry gpasswd newgrp passwd

2. the rest of the bins is installed in usbin and not in ubin, so if ACCT_TOOLS_SETUID is defined, the chmod loop cannot find the bins and throws an error.

passwd command, add salt length option up to 16 characters

Hi all

I read passwd command man page but i not found salt length option

I want to an option specify salt length up to 16 characters

passwd command default creates salt length 6 characters for sha512 ($6$... in /etc/shadow)
--> tested on CentOS 7.5

Anaconda installer (Red Hat/CentOS...) created salt lengh 16 characters

Do I right to suggest this option? Does it necessary?

Tks

ChangeLog

Is there a reason why the ChangeLog file is not updated anymore?

Some projects started to not use their ChangeLog anymore when they switched to GitHub. They just wrote the Changelog in the description of the GitHub release. However when the description contains tag 4.4 only this isn't very helpful.
Some projects propose to look at git log.
Of course one could do that but:

• Sometimtes there are fixup commits so actually several commits give one new functionality, so one cant automate generating the ChangeLog from git log
• If upstream does it all distributions can use it instead of each distribution writing their own ChangeLog

Generally I had the impression that http://pkg-shadow.alioth.debian.org/ was the upstream website of shadow., and also being the Debian site about it.
As get involved states:

The pkg-shadow project on Alioth is used for upstream maintenance of shadow and for the maintenance of the Debian shadow package.

Thus I would have thought that the news is up to date regarding the upstream version of things and not the debian specific things. Meaning 2014-05-09 - New release: 4.2.1 is the last one on the website but on GitHub there are 4.3.0, 4.3.1 and 4.4.

So the website sais 4.2.1 is the latest, and funny enough this on is not even tagged in git, so in this case its very hard to go to git log and just see what was added since last tag. So in this case it would even be more a reason to have a ChangeLog provided by upstream.

I tried to adress this partly in an email.

home page invalid

I can't access to specified home page http://pkg-shadow.alioth.debian.org/

Incompatible chmod -f option

Hello,

The option -f is used in chmod(1) on the files src/Makefile.am and src/Makefile.in. This is incompatible with the implementation of chmod provided by Busybox. The build will fail.

Log SSH_ORIGINAL_COMMAND in nologin

Now nologin logs the login attempt. It could be used to block certain users from logging in. One of the cases would be to prevent interactive logins and remote command execution over ssh.

If an user tries to execute command remotely over ssh and ForceCommand directive applies to the user, sshd populates SSH_ORIGINAL_COMMAND environment variable with the requested command line. E.g., given the following snippet in sshd_config:

Match User baduser
ForceCommand /usr/sbin/nologin

if baduser will try to execute a command, sshd will set SSH_ORIGINAL_COMMAND to the requested command line and execute /usr/sbin/nologin denying the login. However, from the nologin logs it will be hard to figure out, if this baduser really tried to login interactively, execute a command, or just had Emacs TRAMP mode misconfigured.

To address this shortcoming I wrote a special shell some time ago. I realized later, that nologin might be a better and a more universal tool to do the job.

I am opening this issue as I hope to hear the feedback from developers if logging SSH_ORIGINAL_COMMAND in nologin makes sense. If the feedback is positive, I'll submit PR.

Consider adding an option to remove user journals on userdel

Maybe systemd should be handling this itself but just in case,
would it be possible to have userdel have an option to remove /var/log/journal/<machine_id>/user-1001*.journal when the user with id 1001 is deleted?
This would prevent the next user with the same id from reading the old user's data.
For example, when doing userdel testuser2 and useradd testuser3 since they will have the same user id.
userdel already offers to remove mail spool data through an option.

shadow-4.6: 'usermod --prefix' action results in 'invalid pointer' crash

Hey,
if I perform the following operations

> useradd -m test -g users -G audio,video
> mkdir /tmp/etc/
> cp /etc/passwd /etc/group /etc/shadow /etc/gshadow /etc/login.defs /tmp/etc/

and then do
> usermod test -g users -G audio,video,plugdev
it works fine. If I do
> usermod test -g users -G audio,video,plugdev --prefix=/doesnotexist
I get correctly
usermod: group 'audio' does not exist
usermod: group 'video' does not exist
usermod: group 'plugdev' does not exist

However, when I execute
> usermod test -g users -G audio,video,plugdev --prefix=/tmp/
the result is an error message:

*** Error in `usermod': free(): invalid pointer: 0x0000561bc7cc0cc6 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x77c2d)[0x7f5ba13b2c2d]
/lib64/libc.so.6(+0x7f86b)[0x7f5ba13ba86b]
/lib64/libc.so.6(+0x80d81)[0x7f5ba13bbd81]
usermod(+0xf9a8)[0x561bc74189a8]
usermod(+0x8d7c)[0x561bc7411d7c]
usermod(+0x4f72)[0x561bc740df72]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7f5ba135b44a]
usermod(+0x6e3a)[0x561bc740fe3a]
======= Memory map: ========
561bc7409000-561bc7423000 r-xp 00000000 08:04 1318955 /usr/sbin/usermod
561bc7622000-561bc7623000 r--p 00019000 08:04 1318955 /usr/sbin/usermod
561bc7623000-561bc7626000 rw-p 0001a000 08:04 1318955 /usr/sbin/usermod
561bc7626000-561bc7627000 rw-p 00000000 00:00 0
561bc7cbd000-561bc7cde000 rw-p 00000000 00:00 0 [heap]
7f5b9c000000-7f5b9c021000 rw-p 00000000 00:00 0
7f5b9c021000-7f5ba0000000 ---p 00000000 00:00 0
7f5ba03cf000-7f5ba03e5000 r-xp 00000000 08:04 2128933 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1
7f5ba03e5000-7f5ba05e4000 ---p 00016000 08:04 2128933 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1
7f5ba05e4000-7f5ba05e5000 r--p 00015000 08:04 2128933 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1
7f5ba05e5000-7f5ba05e6000 rw-p 00016000 08:04 2128933 /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1
7f5ba05e6000-7f5ba05f1000 r-xp 00000000 08:04 1314827 /lib64/libnss_files-2.25.so
7f5ba05f1000-7f5ba07f0000 ---p 0000b000 08:04 1314827 /lib64/libnss_files-2.25.so
7f5ba07f0000-7f5ba07f1000 r--p 0000a000 08:04 1314827 /lib64/libnss_files-2.25.so
7f5ba07f1000-7f5ba07f2000 rw-p 0000b000 08:04 1314827 /lib64/libnss_files-2.25.so
7f5ba07f2000-7f5ba07fd000 r-xp 00000000 08:04 1314833 /lib64/libnss_nis-2.25.so
7f5ba07fd000-7f5ba09fc000 ---p 0000b000 08:04 1314833 /lib64/libnss_nis-2.25.so
7f5ba09fc000-7f5ba09fd000 r--p 0000a000 08:04 1314833 /lib64/libnss_nis-2.25.so
7f5ba09fd000-7f5ba09fe000 rw-p 0000b000 08:04 1314833 /lib64/libnss_nis-2.25.so
7f5ba09fe000-7f5ba0a13000 r-xp 00000000 08:04 1314832 /lib64/libnsl-2.25.so
7f5ba0a13000-7f5ba0c13000 ---p 00015000 08:04 1314832 /lib64/libnsl-2.25.so
7f5ba0c13000-7f5ba0c14000 r--p 00015000 08:04 1314832 /lib64/libnsl-2.25.so
7f5ba0c14000-7f5ba0c15000 rw-p 00016000 08:04 1314832 /lib64/libnsl-2.25.so
7f5ba0c15000-7f5ba0c17000 rw-p 00000000 00:00 0
7f5ba0c17000-7f5ba0c1e000 r-xp 00000000 08:04 1314835 /lib64/libnss_compat-2.25.so
7f5ba0c1e000-7f5ba0e1e000 ---p 00007000 08:04 1314835 /lib64/libnss_compat-2.25.so
7f5ba0e1e000-7f5ba0e1f000 r--p 00007000 08:04 1314835 /lib64/libnss_compat-2.25.so
7f5ba0e1f000-7f5ba0e20000 rw-p 00008000 08:04 1314835 /lib64/libnss_compat-2.25.so
7f5ba0e20000-7f5ba1137000 r--p 00000000 08:04 2097729 /usr/lib64/locale/locale-archive
7f5ba1137000-7f5ba113a000 r-xp 00000000 08:04 1314369 /lib64/libdl-2.25.so
7f5ba113a000-7f5ba1339000 ---p 00003000 08:04 1314369 /lib64/libdl-2.25.so
7f5ba1339000-7f5ba133a000 r--p 00002000 08:04 1314369 /lib64/libdl-2.25.so
7f5ba133a000-7f5ba133b000 rw-p 00003000 08:04 1314369 /lib64/libdl-2.25.so
7f5ba133b000-7f5ba14e2000 r-xp 00000000 08:04 1314837 /lib64/libc-2.25.so
7f5ba14e2000-7f5ba16e1000 ---p 001a7000 08:04 1314837 /lib64/libc-2.25.so
7f5ba16e1000-7f5ba16e5000 r--p 001a6000 08:04 1314837 /lib64/libc-2.25.so
7f5ba16e5000-7f5ba16e7000 rw-p 001aa000 08:04 1314837 /lib64/libc-2.25.so
7f5ba16e7000-7f5ba16eb000 rw-p 00000000 00:00 0
7f5ba16eb000-7f5ba16ef000 r-xp 00000000 08:04 1321179 /lib64/libattr.so.1.1.0
7f5ba16ef000-7f5ba18ee000 ---p 00004000 08:04 1321179 /lib64/libattr.so.1.1.0
7f5ba18ee000-7f5ba18ef000 r--p 00003000 08:04 1321179 /lib64/libattr.so.1.1.0
7f5ba18ef000-7f5ba18f0000 rw-p 00004000 08:04 1321179 /lib64/libattr.so.1.1.0
7f5ba18f0000-7f5ba18f8000 r-xp 00000000 08:04 1318295 /lib64/libacl.so.1.1.0
7f5ba18f8000-7f5ba1af7000 ---p 00008000 08:04 1318295 /lib64/libacl.so.1.1.0
7f5ba1af7000-7f5ba1af8000 r--p 00007000 08:04 1318295 /lib64/libacl.so.1.1.0
7f5ba1af8000-7f5ba1af9000 rw-p 00008000 08:04 1318295 /lib64/libacl.so.1.1.0
7f5ba1af9000-7f5ba1afc000 r-xp 00000000 08:04 1324958 /lib64/libpam_misc.so.0.82.1
7f5ba1afc000-7f5ba1cfb000 ---p 00003000 08:04 1324958 /lib64/libpam_misc.so.0.82.1
7f5ba1cfb000-7f5ba1cfc000 r--p 00002000 08:04 1324958 /lib64/libpam_misc.so.0.82.1
7f5ba1cfc000-7f5ba1cfd000 rw-p 00003000 08:04 1324958 /lib64/libpam_misc.so.0.82.1
7f5ba1cfd000-7f5ba1d0a000 r-xp 00000000 08:04 1321611 /lib64/libpam.so.0.84.1
7f5ba1d0a000-7f5ba1f09000 ---p 0000d000 08:04 1321611 /lib64/libpam.so.0.84.1
7f5ba1f09000-7f5ba1f0a000 r--p 0000c000 08:04 1321611 /lib64/libpam.so.0.84.1
7f5ba1f0a000-7f5ba1f0b000 rw-p 0000d000 08:04 1321611 /lib64/libpam.so.0.84.1
7f5ba1f0b000-7f5ba1f2e000 r-xp 00000000 08:04 1314838 /lib64/ld-2.25.so
7f5ba2077000-7f5ba20fd000 rw-p 00000000 00:00 0
7f5ba212a000-7f5ba212d000 rw-p 00000000 00:00 0
7f5ba212d000-7f5ba212e000 r--p 00022000 08:04 1314838 /lib64/ld-2.25.so
7f5ba212e000-7f5ba212f000 rw-p 00023000 08:04 1314838 /lib64/ld-2.25.so
7f5ba212f000-7f5ba2130000 rw-p 00000000 00:00 0
7fffb7a16000-7fffb7a38000 rw-p 00000000 00:00 0 [stack]
7fffb7ace000-7fffb7ad1000 r--p 00000000 00:00 0 [vvar]
7fffb7ad1000-7fffb7ad3000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted

reserved identifier violation

I would like to point out that identifiers like "_COMMONIO_H" and "_SHADOWIO_H" do eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Build requirements are undocumented, missing dependency handling sucks

I've recently tried to build version 4.4 of this package and run into (surmountable) problems. If I configure without --enable-man, the build fails with:

you need to run configure with --enable-man to generate man pages

If I then --enable-man, I still get the same error message above. Only after installing packages providing XSL templates, xsltproc and xml2po, are manpages successfully built. It would be wonderul if the build requirements could be clearly documented in a README file and the configure script actually bail if options like --enable-man are passed but cannot be supported (e.g. one of the binary/data deps are missing) rather than silently setting enable_man=no and moving on (and eventually failing with the above error message).

Sign release tags

Could you please sign GPG release tags and/or tarballs? And ideally, also list the fingerprints of the authorized signing GPG key(s) in the README?

Thank you.
Adam

Creating /run/user/_uid_ on login

With systemd being more or less a thing applications begin to move from the usage of /tmp to /run/user/uid (with permissions limited to the user). Some applications fallback to /tmp if /run/user/uid does not exist and others just fail. Since the creation of /run/user/uid relies on the existence of systemd-logind and dbus (with sufficient permissions) and a login interface is a better common denominator it might make sense that login creates this directory (and eventually deletes it on logout if possible).

su double grabs '--'

(Tested on latest master, commit '5f3e3c2c62aae95a694221e43888a1181f979ea4')

Create the following test-file:

#!/bin/sh
echo 0:$0
echo 1:$1
echo 2:$2
echo 3:$3
echo 4:$4

Call it test.sh and make it executable.

Now the following command double grabs '--', which should not happen, as everything after '--' should be just passed through:

thinkbox ~% su harmth -s ./test.sh -- -- -- 1 "2 3" 4
0:./test.sh
1:--
2:1
3:2 3
4:4

Expected output, and output given by coreutil's su:

dev01 ~%% su harmth -s ./test.sh -- -- -- 1 "2 3" 4
Password: 
0:./test.sh
1:--
2:--
3:1
4:2 3

Proposal: Create .lock files on temporal directory

If someone reboot the machine while you're using chpasswd (.lock files created on /etc), the lock files will stay on /etc forever. Maybe you can create these .lock files on /var/run or /tmp (will be cleanup on reboots).

Thoughts?

Proposal: Add shadow utils translations to Translation Project

As an active translator, I see that it's much easier for us if different core translations are somewhat gathered at the same place, and as there already exists an place for free software, Translation Project, (https://translationproject.org/html/welcome.html) that has important projects like for example coreutils. I wonder if it would be possible to also make use of that service for Shadow utils in future translations. The benefits would be: easier overview for translators, and maybe it would attract more active translators.

I found an old proposal for this, https://lists.debian.org/debian-l10n-spanish/2008/03/msg00038.html but nothing happened back then.

message is unclear

Hello,

In kk.po file I see new message
%s: failed to add uid range %lu-%lu from '%s'\
is the phrasefrom '%s' correct here? Shouldn't it be to '%s'?

Thanks,

Startup time over 50 ms

Using login 1:4.5-1 from Debian Sid/unstable on an ASRock E350M1, the time until hostname login: is displayed is over 120 ms according to systemd-bootchart and strace.

268   20:28:44.258325 execve("/bin/login.real", ["/bin/login.real"], 0xbfc28f90 /* 5 vars */) = 0 <0.001994>
[…]
268   20:28:44.383082 write(2, "kodi login: ", 12) = 12 <0.000174>

Please find the strace attached. It’d be great to reduce this substantially.

• login-strace-tt-T.txt

How do you compile this from source?

I can't seem to find out how to compile this. Would someone mind writing simple steps or providing a link? Thanks.

Confusion regarding max login name length

Hi, we have a bug in GNOME (System Settings) where useradd can be called with too-long a username. useradd seems to fail whenever called with a username greater than 32 characters long.

We are actually checking the username length, but getting the max length from the LOGIN_NAME_MAX constant defined by glibc in /usr/include/bits/local_lim.h as the "minimum guaranteed maximum value" for the system limit. If that constant isn't defined, then we fall back to checking sysconf. Either way, the system limit is way larger than the limit enforced by useradd. We think useradd should probably respect the system limits, unless perhaps there is a good reason not to?Presumably we should not be hardcoding a 32-character limit for this?

See also: GNOME #724193, GNOME #766401

compilation error in su.c

Commit 8f1836b causes a compiler error in su.c , because 2 snprintf statements are missing a max length.

shadow/src/su.c

Line 375 in 6fbc11c

should probably be

snprintf (kill_msg, sizeof kill_msg, _(" ...killed.\n"));
snprintf (wait_msg, sizeof wait_msg, _(" ...waiting for child to terminate.\n"));

new version of shadow overdue

version 4.4 is from September 2016 and we had a lot of important fixes since that, including some security fixes. It would be very helpful if a new tarball, let's say 4.4.1, would be available.

Thanks.

Please remove debian packaging related tags from the repository

They are most likely confusing for most people. There is a packaging repository referenced from the Debian package where the tags are present and expected:
https://anonscm.debian.org/gitweb/?p=pkg-shadow/shadow.git

Make chpasswd SELinux aware

Currently chpasswd, if set in a liberal context, can be used in order to modify /etc/passwd and /etc/shadow. If the user has (granted for some strange reason) set up the root user within an selinux sandbox environment, for instance user_u, chpasswd will not check if the user is restricted via selinux context, when PAM is not compiled. Currently investigating with @robopt - seems to be stock configuration in centos.

shadow-4.6: /bin/groups lists supplementary groups twice

Hi,
the new shadow suite's 'groups' tool lists supplementary groups twice:

> useradd -m test -g users -G audio,video
> groups test
audio video audio video users

userdel -R option does not work as expected

When removing users from chroot the userdel still checks their presence with getpwnam(). However this call is expected to fail if the chroot does not contain the required nsswitch libraries. The userdel should not call getpwnam() if operating in chroot.

"Fix user busy errors at userdel" does not solve the problem

Hi!

See line 173 in shadow/libmisc/user_busy.c, there is a place where subuid file will be left open causing
error during user deletion. This can be observed in pseudo environment where /proc is not available.

--force-badname

Hello!

After reading this mailing list thread I'm not sure whether it was intentionally removed, but is there a runtime option or compiler flag that I can use to force is_valid_name() to always return true? If not, would you be open to having it added?

Thanks for your work on this project!

pwck does not moan about entries with wrong column count

The pwck tool checks the entries of /etc/passed and /etc/shadow for correctnes.
At least the pwck tool in version 4.5 of the shadow suite does not moan about entries with 8 columns.

Example: add a line like this in /etc/passed and run pwck:
clamav:x:64:64:ClamAntiVirus:/dev/null:/bin/:/usr/bin/nologin

pwck does not complain.