Bug#1037044: Forced password reset leaves behind failed user@.service unit
Package: systemd Version: 252.6-1 Severity: normal Greetings: It appears that user@.service is left in a failed state when a user logs in over ssh and is forced to reset their password due to expiration. I was able to regularly reproduce this behavior with the process described below. # Create a test user. $ sudo adduser fish ... # Ensure no failed units. $ systemctl list-units --failed ... # Expire the user's password. $ sudo passwd -e fish # Log in via ssh. Properly change the user's password when prompted. $ ssh fish@localhost ... # Here, you will be kicked back out to your prompt after the new # password is set. # Now, note that a failed unit for the user is left behind. $ systemctl list-units --failed UNIT LOAD ACTIVE SUBDESCRIPTION * user@1001.service loaded failed failed User Manager for UID 1001 ... I think the above accurately describes the behavior I'm seeing. It seems odd to me that the failed service lingers even though the user's password has been changed correctly, without any real failures in the process. The user is now able to log in and what not, but systemd indicates a failure. This is an issue for me because these failures can stack up on systems at my work, and monitoring of failed units then indicates a problem where there is not one. Please let me know any thoughts on this. It could be another piece of software that's causing the error. Or, it could be that I have something improperly configured or that I am misinterpreting things. Many thanks, -- Jason Franklin
Bug#1025623: should we deprecate DHOME, GROUPHOMES, LETTERHOMES?
On Tue, Dec 06, 2022 at 07:29:46PM +0100, Marc Haber wrote: > I am wondering whether it is still worth to maintain DHOME, GROUPHOMES > and LETTERHOMES. Installations as big that they need this are likely ot > have a directory service. Personally, I am fine with removing these features since I have never seen a site organize home directories in the way that GROUPHOMES or LETTERHOMES suggests. Every site I have encountered places home directories immediately under "/home", which is the default. I have no clue how many users out there have come to rely on these features, however. Hmmm... Maybe someone else will provide a better-informed opinion. Best, -- Jason Franklin
Bug#1016014: adduser: Broken symlinks in /usr/*/man8 folders. Affects piuparts
On Fri, 2022-11-11 at 12:07 +0100, Bastian Germann wrote: > Control: severity -1 important > > Can you please fix this? This is really annoying for all maintainers who care > about the piuparts test results of their > packages (all maintainers?). I always have to look more closely because I > might have introduced a bug but every time for > the past 4 months it was this issue that comes up. This will lead people to > ignore piuparts and will introduce bugs. I find it odd that our Salsa CI pipeline still shows a green check even though piuparts is emitting an error message about these links. I hope that doesn't indicate some kind of problem with our CI setup. :/ This is simple enough to fix, however. We can always add the links back when up-to-date translations are submitted. I will send up a merge request today and then ping a reviewer about it to move things along. Thanks to Peter, Andreas, and Bastian for being persistent. :) -- Jason Franklin
Bug#1023836: Maintainer scripts should use /bin/sh unless Bash features are required
Package: adduser Version: 3.129 Severity: minor Greetings: One user requested that our maintainer scripts be refactored to use syntax that is compatible with /bin/sh. Since only minor changes are needed to satisfy the request, I figured we could simply go ahead with it. I will send up a merge request shortly. :) Best, -- Jason Franklin
Bug#1008082: How to --lock an account
On Wed, Jul 27, 2022 at 03:21:08PM +0200, Marc Haber wrote: > > Before I start, I want to make sure we agree on what should be done. > > > > I asserted that two things were sufficient: > > 1. Put a '!' in front of the user's password in /etc/shadow > > 2. Expire the account > > > > This makes it trivial to unlock an account with all of its attributes > > intact, including login shell. > > I think that having nologin as a shell has the advantage of giving a > clear error message IF somebody manages to log in to the expired account > with an invalid password. The message with /usr/sbin/nologin is indeed nice. On my system, I get something like... | $ su --login foo | Password: | This account is currently not available. With password locking plus account expiration, I get... | $ su --login fish | Password: | su: Authentication failure I find it odd that I get a password prompt for an account that is expired, but so it is. Changing the shell won't hurt, of course. My only reason for saying it's not necessary is that someone being able to log in to an expired account would indicate a bug somewhere else that should be fixed (in shadow, maybe?). If account expiration cannot be relied upon, we have a bigger security concern, I think. > For a normal user account, I am undecided whether: > > - leave login shell intact, leaving a possible security hole Again, this is where I am not so sure. If there is a security hole, it would be someone else's, right? Account expiration is either reliable or it is not. > - set login shell back to the default when the account gets reenabled > - save login shell somewhere to reinstate if on reenabling. > > I'd say, do it as you see fit, changing that at a later time would be a > rather isolated change so I'm fine with going ahead either way here, > while still having a personal preference for the third possibility, but > I am not the one who decides that. This is fair. As soon as I'm done with the other bug I'm working on, I'll move to this one and proceed with the stateless implementation. Saving and restoring a user's shell can be added later if needed. Sound good? -- Jason Franklin
Bug#152195: Suggested --homeless option may now be redundant
Greetings: I began implementing the solution to this bug just this morning. There are two parts to the fix: 1. Clarify the intent of --no-create-home in the man page. 2. Implement the new --homeless option. I think that #2 has become redundant given that new systems users are now "homeless" by default. This was not the case when we first decided to add the --homeless option. I cannot think of a situation where one would want to have a "homeless" non-system (normal) user. Thus, I now think adding this option would be a mistake. If it is okay, I will skip the implementation of --homeless and just proceed with updating the documentation for the --no-create-home option. Sound good? -- Jason Franklin
Bug#1015907: Remove the unused "get_users_groups" subroutine
Package: adduser Version: 3.124 Severity: minor Greetings: This is a minor change, but it does remove a library function that previously had some purpose. Let me know if this causes problems. Thanks! -- Jason Franklin
Bug#1015781: autopkgtests fail if user foo exists or existed
On Thu, Jul 21, 2022 at 08:27:15AM +0200, Marc Haber wrote: > The tests expect the test environment to be fresh. When I wrote the initial autopkgtests, my thought was that this was the entire design idea of the system. Each stanza in the debian/tests/control file results in the instantiation of a new chroot or container before its named collection of tests is run. The tests in each stanza, of course, use the same environment. That was the reasoning behind saving and restoring /etc/passwd and friends in the Perl BEGIN and END blocks of each test script. Not perfect, but it speeds up the tests. > They relay too much on uids being the same and do not preseed adduser > to provide reproducible uids. I can understand that this is a problem. If new Debian system users or groups are added to the base files, or if default ID ranges change, we have an issue when specific ID numbers are relied upon. This was why my tests mainly picked usernames and not ID numbers. If Debian ever puts the user "foo" in the base system, we'll need to do a find and replace to change "foo" to something else. ID numbers will be harder to change, so they should be avoided or selected dynamically. > Reproducer: > - create test chroot > - adduser --system foo > - deluser foo > - verify that foo is actually gone > - run autopkgtests > - see not just one test failing. This seems like it shouldn't fail. However, there are probably side effects here that the tests handle that aren't handled by doing this interactively first. In principle, I think that picking a set of canonical usernames to work with in tests should be fine. Picking fixed ID numbers is probably not fine. -- Jason Franklin
Bug#1008082: Beginning work
On Wed, Jul 13, 2022 at 11:00:11PM +0200, Marc Haber wrote: > The expire dates are controlled by useradd's configuration file > /etc/login.defs, and the format is documented, so there is nothing too > wrong by just grepping the information from there. For a non-system > account, we would re-establish the default expiration value, or we could > save the expiration date in a state file and read it from there. Otoh, > for a system account, we should probably just disable account expiration > and document that adduser as a policy layer does not handle system > accounts with an expiration date. Sounds reasonable. > We're going to need state for some requested features anyway, sooner or > later. > > The nologin shell has the nice advantage of denying login _with_ _a_ > _message_ should somebody be able to log in to the account by some other > means that might be allowed by weird PAM and ssh stuff. I would like to > do that anyway, albeid not being strictly necessary. Sure. I had thought that expiry would be sufficient. However, if you are saving state after locking, it is simple enough to use the nologin shell as another hardening step. > I'd like to claim that feature and work on it if you're ok with that. > I'm going to create a branch deluser-lock and push frequently, so you > can review what I am doing. I reserve the right to force-push that > branch though. Proceed, of course! Slowness on my part shouldn't hold things up! ;) Best, -- Jason Franklin
Bug#1008082: Beginning work
On Wed, Jul 13, 2022 at 10:18:55PM +0200, Marc Haber wrote: > are you progressing here? If not, I'd like to tackle this with some low > priority. Unfortunately, I have not made any progress on this yet. Too many personal things in the way... > If adduser --lock sets the shell to nologin, how would we restore the > account? Setting shell to /bin/bash, allowing --unlock a --shell option? > Or should we finally introduce a state directory /var/lib/adduser and > save the shell here? I assume you mean to clarify the behavior of "deluser --lock" here. Giving this some thought, I would not go the route of changing any of the user's attributes like the login shell. My understanding is that truly locking an account requires two things: 1. Place a "!" in front of the password field in /etc/shadow. 2. Expire the account. The first makes the password invalid in a way that is easily reversible. The commands "usermod -L foo" and "usermod -U foo" will disable and then re-enable password authentication for user "foo" in this manner. The second requires setting the user's EXPIRE_DATE to 1. This should disable other forms of authentication without modifying any info we would want to save (except for the expire date). See usermod(8) and shadow(5) for more info on locking and expiry. The minimal satisfactory fix would be just a "--lock" option for the deluser command which does both of the above. To undo this, an admin would run "usermod -U foo" and then set the expire date for the account according to site policy. I am not sure if there is a convenient command for doing the latter. > Should we do that in adduser, or should we have a new binary moduser? Not sure how to answer this one. Like I say above, adding only the "--lock" option to deluser minimally satisfies this new requirement. I would say it's up to you! :) -- Jason Franklin
Bug#1012492: /etc/adduser.conf.dpkg-save created by postinst
On Wed, Jun 08, 2022 at 06:01:11PM +0200, Marc Haber wrote:
> On Wed, Jun 08, 2022 at 10:11:48AM -0400, Jason Franklin wrote:
> > Personally, I think we should simply install a default adduser.conf file
> > and remove all of the debconf stuff from the post install script.
>
> That was like the gist of a short discussion I initiated in March, see
> https://lists.debian.org/debian-boot/2022/03/msg00099.html
Aha! Wonderful. There is precedent for this idea.
This thread also explains the context in which this debconf question had
been useful (i.e., the installer). I had not been able to guess this.
We would also be able to finally close this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541620
> We just need to make sure to make a smooth transitoin, testing
> installation and upgrades from a system with a locally changed
> adduser.conf, a locally removed adduser.conf and adduser.conf unchanged
> from the package. Local changes must be preserved.
I had thought this would be gracefully handled by Dpkg, but maybe my
understanding is not complete here.
Simply changing the debian/install file to properly install the default
/etc/adduser.conf file would work, I had thought (also removing all of
the newly obsolete stuff in the maintscripts).
The result would be that installing/upgrading adduser would prompt for
whether or not you want to keep the local version or take the
maintainer's version, etc.
This prompt would depend on whether, for example, --force-confmiss or
--force-conf{old,new} are passed to Dpkg, usually via apt.
At least I thought that's how it would work.
If we're on the same page here, should I put a patch together?
--
Jason Franklin
Bug#1012492: /etc/adduser.conf.dpkg-save created by postinst
On Wed, Jun 08, 2022 at 11:50:53AM +0200, Tomáš Virtus wrote: > Adduser's postinst script creates /etc/adduser.conf.dpkg-save file on > debootstrap's root filesystem, that is, even if /etc/adduser.conf > doesn't exist prior to package installation. Greetings: Personally, I think we should simply install a default adduser.conf file and remove all of the debconf stuff from the post install script. By installing the file directly, we will cause the adduser package to own the conffile as one would expect. Debsums will work, dpkg -S will work, etc. This would also lead to a resolution of this bug: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/1873519 I have never used the debconf settings that adduser has, but the ability to use config-package-dev would be fantastic. How impactful would it be to remove the debconf stuff? I'd be happy to whip up a patch to do this, but I don't want to just blow away debconf settings that people rely upon. -- Jason Franklin
Bug#1008082: Beginning work
Greetings: I plan to start work on this issue in the next few days. Let me know if this conflicts with anyone's plans! Best, -- Jason
Bug#868568: [Pkg-shadow-devel] Bug#868568: Bug#868568: Possible cause of deluser problem: subordinate user IDs
On Tue, 2022-03-08 at 18:39 +, Ben Harris wrote:
> On Tue, 8 Mar 2022, Serge E. Hallyn wrote
>
> > So deluser was doing the right thing, right?
> >
> > The bug is how you got into this state? Either the adduser for
> > the high uid should have checked for it being a delegated subuid,
> > or the adduser which added the subuids to the lower subuid should
> > have refused when the higher subuid existed as a uid.
>
> As far as I can see, there is no checking for collisions in either
> direction: useradd depends on the ranges [UID_MIN,UID_MAX] and
> [SUB_UID_MIN,SUB_UID_MAX] not overlapping, and issues a warning if you
> assign a static UID outside the specified range.
Serge:
This is something that has recently gotten my attention in my adduser
maintenance efforts. I am trying to help where I can to work around it
and to collaborate with shadow on the issue to get at an optimal
solution.
adduser has its own UID ranges set in /etc/adduser.conf. These variables
are the ones that matter...
> FIRST_SYSTEM_UID=100
> LAST_SYSTEM_UID=999
> FIRST_SYSTEM_GID=100
> LAST_SYSTEM_GID=999
> FIRST_UID=1000
> LAST_UID=5
> FIRST_GID=1000
> LAST_GID=5
As far as I can tell, adduser has no concept of a "subordinate UID"
(neither do I for that matter). I was not familiar with this feature
until recently. This is something I'll have to read about.
The latest upload of adduser (v3.120) uses a naive technique of passing
through its own system user UID range settings to the useradd call. See
below...
('/usr/sbin/useradd', '-r',
'-K', sprintf('SYS_UID_MIN=%d', $config{'first_system_uid'}),
'-K', sprintf('SYS_UID_MAX=%d', $config{'last_system_uid'}),
'-d', $home_dir,
'-g', $ingroup_name,
'-s', $shell,
'-u', $new_uid,
This technique has the benefit that when you use "adduser" you make use
of adduser settings with no warnings from useradd. Likewise, using
useradd obviously still reads from /etc/login.defs.
However, it does not solve the problem that we have two places for the
settings to be specified. Maybe this is not as confusing as I think. The
adduser tool uses /etc/adduser.conf and useradd uses its own file. I
suppose it's on the user to know which file configures which tool.
Other than having adduser pass through its own settings to avoid
"useradd" warnings, I'm not sure what else can be done to reconcile this
divergence. It has existed for a while.
Let me know if you have any thoughts! Thanks!
--
Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Fri, 2022-02-25 at 02:45 -0600, Daniel Lewart wrote: > Also "sudo apt install openssh-server" warns: > useradd warning: sshd's uid 116 outside of the UID_MIN 1000 and > UID_MAX 6 range. Daniel: Thanks for making note of this. Using "-r" does solve the issue, but more needs to be done to ensure that other functionality is not altered unintentionally. To those interested, a fix for this is pending review and will be included in the next upload. -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Tue, 2022-02-22 at 15:02 +0100, Marc Haber wrote: > adduser --system should enforce policy for system users. The local > administrator is free to ignore Debian policy as they see fit. adduser > should not enforce things on the local admin that don't apply to them. > > Maybe we add, some time in the future, an option --ignore-policy that a > local admin can use, so that maintainer scripts get the support of > policy enforcement. I agree with this. The strictness should be something that can be disabled if the local administrator so desires. > > If useradd is intended to replace adduser, I would like to know as most > > of my work would be lessened in importance. > > I don't think there is any such intention in Debian. There is simply no > mechanism to bring this forward other than talking and convincing each > and every package maintainer. It would be a ton of work. That's for sure. -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-20 at 10:03 +0100, Ricardo Fraile wrote: > Only to point that adduser is the recommended way to handle accounts in > maintainer scripts [1] and Debian Code Search reports 267 packages using > it [2], but dh_sysusers [3] seems to handle the same task on the > packages and works with useradd under the hood too. There is certainly some work to be done to reconcile the three different ways of managing users. There needs to be: - a "right way" to add a system user from a package - a "right way" to add a system user from the command line - a "right way" to do low-level user management tasks I had envisioned "adduser" as a Debian policy enforcer on top of the more distribution-agnostic tools from shadow. But, it is true now that some features are confusingly duplicated across these methods. Notably, there are settings for system user UID ranges in both /etc/login.defs and /etc/adduser.conf. There may be value in keeping "adduser" as a higher level tool that can do helpful things by default (e.g., avoid forbidden UIDs, avoid UID reuse, do additional clean up of at jobs w/o need for configs, etc.). I am unsure how to proceed, but I know it will require working well with the shadow maintainers. I think I'll start a discussion through the proper channel. Thanks! -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-13 at 19:18 +0100, Marc Haber wrote: > On Sun, Feb 13, 2022 at 12:27:26PM -0500, Jason Franklin wrote: > > That warning is not emitted here when "-r" is added to the call made > > from within adduser. The range discrepancy needs to be sorted out with > > discussion, I think. > > Policy also helps here, it's rather explicit in defining the uid ranges. > Are we in line with policy? Adduser is in line with policy for the moment. Improvements can be made in this regard. For example, some UIDs are explicitly forbidden by policy, but adduser and useradd allow them. These should be blocked, and tests should be written to prove this. > Useradd is more and more taking over functionality that has > traditionally been implemented in adduser. Maybe they're working towards > adduser just being a shim for backwards compatibility. Do you want me to > reach out to them? Please do. I am actually a bit worried that my work is in vain. The useradd utility does have quite a few features that clash with or overtake those previously offered by adduser. If useradd is intended to replace adduser, I would like to know as most of my work would be lessened in importance. The questions is: Can adduser offer features that admins want and that useradd lacks? I think the answer to the above question is "yes", but we need to make sure we know what these additional features are. :/ I'm a bit uncertain as to where I stand in this regard. Thanks, -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-13 at 18:14 +0100, Marc Haber wrote: > Should useradd emit a warning in this case? I mean, we WANT the low UID > in this case. Is it inside the limits of a low-level tool to impose its > own standards on the system or is this possible a bug in useradd? As part of this bug, we will need to have a conversation with the "login" maintainers about how these ranges are to be configured. Currently, useradd has its own range settings in /etc/login.defs, and adduser has its own in /etc/adduser.conf. adduser can be written to ignore the former completely in its useradd invocation. However, having such a setting in two places may be a bit confusing. That warning is not emitted here when "-r" is added to the call made from within adduser. The range discrepancy needs to be sorted out with discussion, I think. -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-13 at 16:04 +0100, Ricardo Fraile wrote: > Adding _tuptime user... > useradd warning: _tuptime's uid 106 outside of the UID_MIN 1000 and UID_MAX > 6 range. > Created symlink /etc/systemd/system/multi-user.target.wants/tuptime.service → > /lib/systemd/system/tuptime.service. > Processing triggers for man-db (2.10.0-2) ... > >* What outcome did you expect instead? > Install the package without "useradd warning" prompt. Ricardo: I also came across this warning when investigating this bug. When I get this bug fixed, the warning will go away. Thanks! -- Jason Franklin
Bug#1004710: Please pass "-r" to useradd when needed
On Fri, 2022-02-11 at 15:32 +0100, Marc Haber wrote: > How about doing a release with all accumulated changes? It's called > unstable for a reason, and frankly, I don't feel like putting ourselves > into a rush just because another package broke ours. I am certainly on board with this. Rushing is never good. We will take our time and do this right. :) It looks like Johannes will be able to work around this on his end for now. I will put together a PR with tests in the near future to get this fixed the right way. -- Jason Franklin
Bug#1004710: Please pass "-r" to useradd when needed
On Fri, 2022-02-11 at 07:21 +0100, Johannes Schauer Marin Rodrigues wrote: > I can also see how setting the -r option might have unintended side-effects. > > But the information you found already helps me to work around this problem > from > the side of my package mmdebstrap. :) Oh, cool! This is great to hear. It takes some of the time crunch off. There are several useradd features that need to be incorporated into the adduser code. This needs to be done carefully. The "-r" option is one such feature. I will confirm this bug and make it a priority to introduce this fix into the code with proper review and tests and what not. Thanks! -- Jason Franklin
Bug#1004710: Please pass "-r" to useradd when needed
Johannes: I took a bit of time to look at this further. I think that adding "-r" to the useradd call found in adduser will not break anything. It's the best way to go ahead and fix this, and it is the most forward-looking solution. To Marc: I would like to implement this with a proper autopkgtest in adduser that proves that "/var/mail/foo" is not created by default when system user "foo" is added. This will integrate nicely with the other work I'm doing. I could branch off of the 3.118 tag in the Debian/adduser repository and submit a PR with the fix to master. Then, the new package with this fix could be built off of the feature branch before the merge (the hotfix branch). We can then merge with master (resolving conflicts) to integrate with the changes we don't want to release yet. Does this all sound reasonable? -- Jason Franklin
Bug#1004710: Please pass "-r" to useradd when needed
Greetings: I have been helping Marc Haber with some of the issues in adduser, so I suppose it is appropriate for me to chime in here. Thanks so much for the report and for the investigative work so far! Here are my thoughts... The "good" chroot has version 1:4.8.1-2 of passwd, and the "bad" chroot has version 1:4.11.1+dfsg1-1 of passwd. The changes between these two versions were substantial. > Quoting Bálint Réczey (2022-02-10 22:46:50) > > Apparently useradd correctly guessed system user ranges in the past, > > but this is not something to rely on. I do not think "useradd" ever attempted to guess whether a UID being added was in the system user range. Instead, it looks like hardcoded settings in the source code changed between the two versions above. To see this, you may reference the upstream shadow repository... Commit: https://github.com/shadow-maint/shadow/commit/bbf4b79bc49fd1826eb41f6629669ef0b647267b The key part of that change was this: - static const char *def_create_mail_spool = "no"; + static const char *def_create_mail_spool = "yes"; The "adduser" command never set the "-r" option previously, but the default in the upstream source was to not create the mail spool directories. Thus, this problem never surfaced. > the recent upload of shadow 1:4.11.1+dfsg1-1 made above patch necessary as > otherwise useradd will create empty directories in /var/mail and > /var/spool/mail for the system users _apt, systemd-network and > systemd-resolve. > This in turn breaks the testsuite of my package mmdebstrap. I think setting the "-r" option is the right approach, but we need to make sure that the new option doesn't do anything else that we do not expect for it to do. I can see that it does more than just omit creating the mail spool by default. The "passwd" package could be patched temporarily to undo the change from "no" to "yes" above. That would put us back at the old behavior for the time being. This patch could be removed in the not-to-far future, as I am committed to helping with supporting adduser and with fixing bugs new and old, including this one. :) Looking forward to hearing what Marc and others think on this one. Thanks! -- Jason Franklin
Bug#473379: Recommendation to remove the check and the warning
Greetings: I thought I would go ahead and confirm this one. I noticed it myself today, and I wanted to follow up here. I recommend that we remove the check and the warning entirely. First, the warning is already incorrect. It may mislead someone into thinking that they can remove a group that still as members. Second, an empty group is in many if not most cases NOT an error. There are several standard groups that may be empty on a given system (e.g., "cdrom" or "adm"). Third, I believe that this is a case of "deluser" being a bit too helpful. We should only be worried about whether a group is empty or not when deleting a group. Otherwise, it is on the sysadmin to check for empty groups if they are not desired. Is my reasoning sound here? If so, I'll work on this one after I finish the bug I'm working on currently. It should be an easy win! -- Jason Franklin
Bug#559423: Update on bug #559423 (--system exit status)
Greetings: The bug that I most recently started working on was this one. The latest commits on the feature branch I have for this can be found on Salsa... https://salsa.debian.org/deadjoe/adduser/-/commits/DBTS-559423-delgroup-status N.B. This branch will probably be deleted when it's merged, so the above link may break one day. This bug is my first attempt at writing a new functional test. Notice that the test CI step is failing during autopkgtest execution with the proper expected failure (at commit d4f37a2a). Next steps include adding a fix for this new failing test to close this bug and writing a second test while implementing the proper set-up/tear- down routines to be called in between. I have arrived at a stopping point, having just a few questions... 1. I have commented out the invocation of the legacy test suite in the test metadata file (debian/tests/control) to isolate my work. This is temporary to make sure nothing interferes with my new tests. Should we continue to support the legacy test suite? 2. In light of the above, does autopkgtest run the tests from each stanza in debian/tests/control in a new/clean testbed? How good is the isolation between stanzas at test runtime, and what can I rely on regarding this? I would like to make sure old-style tests don't interfere with my new-style tests. Hopefully, a method for adding new tests can be established that is immediately obvious to reviewers and contributors. That will clear a path for other contributors to add tests when they provide patches. That's all for now. Let me know what you think! -- Jason Franklin
Bug#152195: Question on the use of "/nonexistent"
On Sun, 2021-12-19 at 12:08 +0100, Marc Haber wrote: > I don't have anything to add but my support for the way that has been > unanimously lined out in this discussion. Jason, you have my "go" to do > those changes, and if it would be my choice it'd be --homeless ;-) > > Otoh, --nonexistent-home would be more serious, but there is no much > different to --home /nonexistent. Most excellent! I am happy that everyone else seems to be content with the result of this discussion. It sounds like we have a plan! :) There are three improvements to make here: 1. Augment the documentation for "--no-create-home" to clarify intent. 2. Implement the "--homeless" option. (This is tentative!) 3. Add tests for these options! For #1: This is mainly to help less-experienced Debian admins such as myself who are only exposed to creating users in the standard way. For #2: A separate option is nice because it does not rely on a specific directory value (e.g., "/nonexistent") in a script, which is a detail. It will need to be mutually exclusive with the "--home" option, and it will need to imply the passing of "--no-create-home". Don't worry, I won't try to add something like this without automated tests! For #3: I am currently trying to get up to speed with how to use autopkgtest in adduser. I am reluctant to change anything other than docs until I have a corresponding test for what I want to change. Once I have a good workflow, I'll come back to this issue and make the changes. I suppose I can re-classify this as "minor" and "confirmed" for now. I would say "wishlist", but the main issue here is clarifying the docs, and the new option ultimately might not be added. I am still new to classifying bugs, so feel free to overwrite my changes if they seem improper! That will help me learn if I get it wrong. Thanks to Marc and everyone else for clarifying things! -- Jason Franklin
Bug#152195: Question on the use of "/nonexistent"
On Sat, 2021-12-18 at 19:22 +0100, Bill Allombert wrote: > This seems to be a misunderstanding of the purpose of --no-create-home. > This option does not say that the user does not have a home directory, > but that it should not be created by adduser, and instead will be create > later by some other procedure, for example by setting pam_mkhomedir > to create it on first login, or by mounting a NFS filesystem on /home, > etc. > > In this bug report, users used --no-create-home but failed to create the > home directory themselves. > It seems that what they wanted to do was '--home /nonexistent' Agreed. I see the difference now. I suppose I had thought that the discussion on this report happened before the usage of /nonexistent was standard. > I would suggest you add an option --no-homedir that do '--home /nonexistent' > or whatever is appropriate and close this bug. This is an interesting idea. It would at least provide a distinction for the intended result and it would guide people toward complying with Debian Policy in the case that a user is not supposed to have a home directory. -- Jason Franklin
Bug#152195: Question on the use of "/nonexistent"
On Sat, 2021-12-18 at 10:16 -0800, Russ Allbery wrote: > The documentation says simply: > >--no-create-home > Do not create the home directory, even if it doesn't exist. > > Passing --no-create-home therefore does not *change* the home directory, > and should not change the home directory, since that would defeat its > entire purpose. The home directory is still set the same as before, > including any defaults. adduser just doesn't try to create it or check if > it exists, because this should be handled external to adduser. > > If a user should have a nonexistent home directory, --home /nonexistent > should be passed to adduser. I follow you. This is an important distinction. I suppose a note in the documentation could clarify things for users who may not be aware of these other usage scenarios. Thanks! -- Jason Franklin
Bug#1001863: adduser: EXCLUDE_FSTYPES not respected with --remove-all-files
Adam: Thanks so much for the thorough bug report! >From looking at the code, I also cannot see how "--remove-all-files" could possibly respect the "EXCLUDE_FSTYPES" option. This does not agree with the documentation at all. Note that deluser.conf(5) currently has this to say... EXCLUDE_FSTYPES A regular expression which describes all file systems which should be excluded when looking for files of a user to be deleted. Defaults to "(proc|sysfs|usbfs|devpts|tmpfs|afs)". This seems like a pretty clear contract with the user to skip deletion of data residing on file systems of these types. I will mark this bug as confirmed so that it can be handled in a future release. Thanks again! -- Jason Franklin
Bug#960318: passwd: pwck does not recognize meaning of "/nonexistent" home directory
Package: passwd
Version: 1:4.5-1.1
Severity: normal
Tags: patch
Dear Maintainer(s):
The included patch helps the "pwck" command to function more helpfully
on Debian by having it recognize the convention of using "/nonexistent"
for the home directory of a user who intentionally does not have a home
directory.
This will allow "pwck" to properly succeed when some users have this
string as their home directory. It will prevent a false failure and
false error messages such as these:
user 'lp': directory '/nonexistent' does not exist
user 'news': directory '/nonexistent' does not exist
user 'uucp': directory '/nonexistent' does not exist
...
user 'www-data': directory '/nonexistent' does not exist
user '_apt': directory '/nonexistent' does not exist
user 'nobody': directory '/nonexistent' does not exist
pwck: no changes
The patch has already been accepted upstream. See the link below to the
GitHub pull request for more discussion...
https://github.com/shadow-maint/shadow/pull/251
The patch follows here:
--- a/README
+++ b/README
@@ -69,6 +69,7 @@ Guy Maor
Hrvoje Dogan
Jakub Hrozek
Janos Farkas
+Jason Franklin
Jay Soffian
Jesse Thilo
Joey Hess
--- a/etc/login.defs
+++ b/etc/login.defs
@@ -295,7 +295,7 @@ CHFN_AUTH yes
# any combination of letters "frwh" (full name, room number, work
# phone, home phone). If not defined, no changes are allowed.
# For backward compatibility, "yes" = "rwh" and "no" = "frwh".
-#
+#
CHFN_RESTRICT rwh
#
@@ -383,6 +383,14 @@ CHFN_RESTRICT rwh
DEFAULT_HOME yes
#
+# The pwck(8) utility emits a warning for any system account with a home
+# directory that does not exist. Some system accounts intentionally do
+# not have a home directory. Such accounts may have this string as
+# their home directory in /etc/passwd to avoid a spurious warning.
+#
+NONEXISTENT/nonexistent
+
+#
# If this file exists and is readable, login environment will be
# read from it. Every line should be in the form name=value.
#
--- a/lib/getdef.c
+++ b/lib/getdef.c
@@ -105,6 +105,7 @@ static struct itemdef def_table[] = {
{"MAIL_FILE", NULL},
{"MAX_MEMBERS_PER_GROUP", NULL},
{"MD5_CRYPT_ENAB", NULL},
+ {"NONEXISTENT", NULL},
{"PASS_MAX_DAYS", NULL},
{"PASS_MIN_DAYS", NULL},
{"PASS_WARN_AGE", NULL},
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -152,6 +152,7 @@ login_defs_v = \
MD5_CRYPT_ENAB.xml \
MOTD_FILE.xml \
NOLOGINS_FILE.xml \
+ NONEXISTENT.xml \
OBSCURE_CHECKS_ENAB.xml \
PASS_ALWAYS_WARN.xml \
PASS_CHANGE_TRIES.xml \
--- a/man/login.defs.5.xml
+++ b/man/login.defs.5.xml
@@ -67,6 +67,7 @@
+
@@ -203,6 +204,7 @@
_CRYPT_ENAB;
_FILE;
_FILE;
+
_CHECKS_ENAB;
_ALWAYS_WARN;
_CHANGE_TRIES;
--- /dev/null
+++ b/man/login.defs.d/NONEXISTENT.xml
@@ -0,0 +1,41 @@
+
+
+ NONEXISTENT (string)
+
+
+ If a system account intentionally does not have a home directory
+ that exists, this string can be provided in the /etc/passwd
+ entry for the account to indicate this. The result is that pwck
+ will not emit a spurious warning for this account.
+
+
+
--- a/man/pwck.8.xml
+++ b/man/pwck.8.xml
@@ -30,6 +30,7 @@
-->
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
+
@@ -266,6 +267,7 @@
tool:
+
_MAX_DAYS;
_MIN_DAYS;
_WARN_AGE;
--- a/src/pwck.c
+++ b/src/pwck.c
@@ -527,12 +527,16 @@ static void check_pw_file (int *errors,
* Make sure the home directory exists
*/
if (!quiet && (access (pwd->pw_dir, F_OK) != 0)) {
+ const char *nonexistent =
getdef_str("NONEXISTENT");
+
/*
-* Home directory doesn't exist, give a warning
+* Home directory does not exist, give a
warning (unless intentional)
*/
- printf (_("user '%s': directory '%s' does not
exist\n"),
- pwd->pw_name, pwd->pw_dir);
- *errors += 1;
+ if (NULL == nonexistent || strcmp (pwd->pw_dir,
nonexistent) != 0) {
+ printf (_("user '%s': directory '%s'
does not exist\n"),
+ pwd->pw_name,
pwd->pw_dir);
+ *errors += 1;
+ }
}
}
Thanks for considering this mod
Bug#934185: libkscreenlocker5: fails to accept correct pin after entering pin less than 6 chars with libpam-poldi
Package: libkscreenlocker5 Version: 5.14.5-1 Severity: grave Justification: causes non-serious data loss Greetings, I am working on a machine that is configured to use libpam-poldi for user authentication with GPG smart cards. When the screen locker is engaged and the user enters a PIN that is under six characters in length, two things happen: 1. The screen locker will no longer accept a valid PIN. 2. The /var/log/auth.log file fills up with "PIN too short" messages. The messages in auth.log appear as below: Aug 2 09:10:46 hostname kcheckpass[9734]: PIN too short Aug 2 09:10:46 hostname kcheckpass[9734]: PIN too short Aug 2 09:10:46 hostname kcheckpass[9734]: PIN too short ... This problem is clearly due to some issue at the boundary of kcheckpass and libpam-poldi. However, I am not yet able to determine which of the two is responsible. I have pulled down the source code of both packages, and I am actively working on fixing the problem. I can see where libpam-poldi obviously will not accept a PIN less than 6 chars in length. Refer to the libpam-poldi source tree in the file... src/pam/auth-support/getpin-cb.c to confirm this. Ideally, I would need to do the following to fix this issue: 1. Compile libpam-poldi with debugging support. 2. Compile kcheckpass with debugging support. 3. Run kcheckpass with GDB to find where the conversation breaks down when a short PIN is provided. This would tell us if the bug is with kcheckpass or with libpam-poldi. Let me know if you can help me implement the plan of attack above, especially if you can offer or refer me to instructions on building and running kcheckpass from the shell. That would be very helpful! I am quite invested in fixing this, and I'll gladly help in any way I can. Please advise on a course of action. Best wishes, Jason Franklin -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable'), (100, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libkscreenlocker5 depends on: ii kpackagetool5 5.54.0-1 ii libc6 2.28-10 ii libkf5configcore5 5.54.0-1 ii libkf5configgui5 5.54.0-1 ii libkf5coreaddons5 5.54.0-1 ii libkf5crash5 5.54.0-1 ii libkf5declarative5 5.54.0-1 ii libkf5globalaccel-bin 5.54.0-1 ii libkf5globalaccel5 5.54.0-1 ii libkf5i18n55.54.0-1 ii libkf5idletime55.54.0-1 ii libkf5notifications5 5.54.0-1 ii libkf5package5 5.54.0-1 ii libkf5quickaddons5 5.54.0-1 ii libkf5waylandclient5 4:5.54.0-1 ii libkf5waylandserver5 4:5.54.0-1 ii libkf5windowsystem55.54.0-1 ii libpam0g 1.3.1-5 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5dbus55.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5widgets5 5.11.3+dfsg1-1 ii libqt5x11extras5 5.11.3-2 ii libseccomp22.3.3-4 ii libstdc++6 8.3.0-6 ii libwayland-client0 1.16.0-1 ii libwayland-server0 1.16.0-1 ii libx11-6 2:1.6.7-1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb11.13.1-2 ii libxi6 2:1.7.9-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.14.5-1 libkscreenlocker5 suggests no packages. -- no debconf information
