[linux-pam] #54: Make strings used on login screen user-friendly
by fedora-badges
#54: Make strings used on login screen user-friendly
--------------------------+------------------------------
Reporter: catanzaro | Owner: pam-developers@…
Type: enhancement | Status: new
Priority: minor | Component: modules
Version: 1.2.x | Keywords:
Blocked By: | Blocking:
--------------------------+------------------------------
Hi,
For Fedora Workstation we would like to make some changes to strings in
Linux-PAM that appear on the login screen, to make the user experience a
bit more simple. Some of these strings contain technical terminology that
we'd like to remove:
"You are required to change your password immediately (root enforced)."
The problem with this string is that we expect users do not understand
what a root account is.
"(current) UNIX password:" "Enter new UNIX password:" "Retype new UNIX
password:" The problem with these strings is that we do not expect users
to understand what UNIX is. A user might become confused as to how a UNIX
password differs from a normal password, and not realize they are the same
thing.
At first I thought we might want to add an opt-in configuration setting to
tell PAM to avoid technical terminology in its prompts, in order to avoid
changing the strings sent to command-line applications like passwd (where
the user is expected to understand concepts like UNIX and root), but since
the required changes are so simple, I think it's probably best to avoid
this...?
--
Ticket URL: <https://fedorahosted.org/linux-pam/ticket/54>
linux-pam <http://fedorahosted.org/linux-pam>
The Linux-PAM (Pluggable Authentication Modules) project
8 years
[linux-pam] #46: Fix build with musl libc
by fedora-badges
#46: Fix build with musl libc
----------------------+------------------------------
Reporter: yousong | Owner: pam-developers@…
Type: defect | Status: new
Priority: major | Component: library
Version: | Keywords:
Blocked By: | Blocking:
----------------------+------------------------------
Hi, patch files in the attachments are produced when building libpam
within OpenWrt. Not long ago, OpenWrt switched to musl as the default
libc which is relatively and different from other implementations, e.g.
crypt() function is part of musl-libc itself, many old functions are
dropped from the implementation, etc.
--
Ticket URL: <https://fedorahosted.org/linux-pam/ticket/46>
linux-pam <http://fedorahosted.org/linux-pam>
The Linux-PAM (Pluggable Authentication Modules) project
8 years
[linux-pam] #53: pam_lastlog should have option to resolve hostname
by fedora-badges
#53: pam_lastlog should have option to resolve hostname
--------------------------+------------------------------
Reporter: chowbok | Owner: pam-developers@…
Type: enhancement | Status: new
Priority: trivial | Component: modules
Version: 1.2.x | Keywords:
Blocked By: | Blocking:
--------------------------+------------------------------
pam_lastlog should be able to report what host the user last logged in
from, not just the IP. It would be very cool if this could be added as an
option.
--
Ticket URL: <https://fedorahosted.org/linux-pam/ticket/53>
linux-pam <http://fedorahosted.org/linux-pam>
The Linux-PAM (Pluggable Authentication Modules) project
8 years
[Fwd: Re: GCC 6 -Wnonnull is too aggressive]
by Tomas Mraz
Apparently our usage of __nonnull__ attribute is not completely aligned
with what gcc developers mean with it. Use of the attribute declares
that the parameter can never be NULL which means that the checks in the
IF_NO_PAMH for example can be removed by the compiler during the
optimization. We would need to remove the __nonnull__ attribute or at
least add -fno-delete-null-pointer-checks to the default CFLAGS.
I'd prefer removing the __nonnull__.
What do you think?
Tomas
-------- Forwarded Message --------
From: Jonathan Wakely <jwakely(a)fedoraproject.org>
Reply-to: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
To: Development discussions related to Fedora <devel(a)lists.fedoraprojec
t.org>
Subject: Re: GCC 6 -Wnonnull is too aggressive
Date: Fri, 19 Feb 2016 12:30:58 +0000
On 19/02/16 10:49 +0100, Petr Spacek wrote:
> The thing is that some developers (e.g. me and ISC :-)) do not think
> that
> assert() should be used only in debug builds.
>
> E.g. BIND itself is written in "Design by contract" spirit and
> asserts are
> used all over the place to make sure that code which does not behave
> as
> intended is killed as soon as possible (and thus prevented from doing
> collateral damage). Call it defensive programming if you wish.
That's fine. Don't use attribute((nonnull)) then.
It's illogical to promise the compiler that something will never,
ever, ever be null, but also check whether it's null. If you're not
100% certain it can't be null, then you lied to the compiler. If you
are 100% certain it can't be null then the assert is redundant and can
be removed.
If you're only 99.999% certain, and so the assert serves a useful
purpose, then don't make promises that you can't keep.
If you just want to advise the compiler that something *probably*
won't be null, and tell it to optimize based on that assumption, then
you can use __builtin_expect() to provide that hint (although I
wouldn't actually recommend doing so).
Don't make a promise when you mean to give a hint.
--
devel mailing list
devel(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.or
g
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8 years, 2 months
Add option to ignore password expiration in pam_unix
by Tomas Mraz
Hello,
OpenSSH sshd calls (correctly) pam_acct_mgmt even for authentication
methods that do not involve user passwords. The attached patch allows
pam_unix to optionally ignore the password expiration. What do you
think about it? Would it be OK to commit if I provide also
documentation of the no_pass_expiry option?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8 years, 2 months