| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pam_console is being removed as it was replaced by ConsoleKit. The
changes in this commit just remove pam_console from the service files.
If you are curious about the removal check the Fedora System-Wide Change
proposal linked below.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1822228
Relates: https://fedoraproject.org/wiki/Changes/RemovePamConsole
Relates: https://bugzilla.redhat.com/show_bug.cgi?id=2166692
Signed-off-by: Iker Pedrosa <ipedrosa@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
gdm-pin was an experimental feature that was going to get added to
gnome-shell many years ago. It never happened and these days it
would probably be implemented a little different anyway.
(It would probably use a gdm pam extension)
There's no point keeping this service file around that we aren't
using, so this commit drops it.
Closes: https://gitlab.gnome.org/GNOME/gdm/-/issues/731
|
| |
|
|
|
| |
These files haven't been used since multistack became
a hard requirement.
|
| |
|
|
|
|
|
|
|
|
|
| |
In theory sending the password to them could be beneficial.
If for instance, they have pam_krb5 or pam_ecryptfs or pam_sss.
In practice, the stacks will fail if the passwords don't match,
and prevent autologin from continuing.
This commit just sidesteps them for now. Eventually,
authconfig/et al, will need to get updated to accomodate us.
|
| |
|
|
| |
It prevents postlogin from getting run.
|
| |
|
|
|
|
|
|
|
|
|
| |
If pam_gdm fails we shouldn't call into pam_unix since it can lead
to the system asking for a password, and autologin isn't equipped for
that.
This commit changes the pam configuration to jump to pam_permit if
pam_gdm fails.
https://bugzilla.gnome.org/show_bug.cgi?id=770612
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the user has an encrypted disk then systemd will cache the password
they type into the keyring. It makes sense to try to use this password
for automatic login purposes first, since on single user machines,
the sole user password is likely to match the disk password.
Of course if it doesn't work we'll fall back to the old way of doing
automatic login without a password (and then the user will have to
manualy enter if they need to for gnome-keyring or whatever)
https://bugzilla.gnome.org/show_bug.cgi?id=769950
|
| |
|
|
|
|
|
|
| |
The login screen user account won't ever have a password or get locked,
so there's no reason to run the system-auth password and account
stacks for the login screen launch environment.
https://bugzilla.gnome.org/show_bug.cgi?id=764472
|
| |
|
|
|
|
| |
It was deprecated in 3.16 to be removed in 3.18
https://bugzilla.gnome.org/show_bug.cgi?id=743940
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 76d26d8c1c37c6bd38bcac082d5cc62670fe5d39.
It breaks pam_ecryptfs.
Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1174366
https://bugzilla.gnome.org/show_bug.cgi?id=743045
|
| |
|
|
|
| |
pam_nologin is supposed to prevent users from logging in, not prevent
the login screen from coming up.
|
| |
|
|
|
|
|
| |
It's just used in practice to inflict ugly "Last Login" messages
on the GDM screen
https://bugzilla.gnome.org/show_bug.cgi?id=728281
|
| |
|
|
|
|
| |
This commit properly hooks in gnome-keyring into the password
stack, so password changes are caught at login time, and the keyring
is appropriately rekeyed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Originally, the idea was to have pam-pin as an optional module in gdm-password,
but since the PIN can easily get misconfigured, what we want here is
to give the user a choice at the login screen, so we want two different
conversations at the same time.
The pin module is marked requisite, so if it fails we stop before touching
the other modules and immediately report to the greeter (which then goes
on with gdm-password)
https://bugzilla.gnome.org/show_bug.cgi?id=693968
|
| |
|
|
|
|
|
|
|
|
| |
From https://bugzilla.redhat.com/show_bug.cgi?id=882385:
"The loginuid is for actual logins by people. Its not intended for
system use. All daemons should have loginuid set to -1, meaning that its
a system process and not related to activity by a person."
https://bugzilla.gnome.org/show_bug.cgi?id=693152
|
| |
|
|
|
|
|
| |
It's an issue that comes up over and over again.
Give in to the peer pressure and allow root login
by default. We warn in gnome-session now anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
"GdmWelcomeSession" was always a sort of bad name, as it is not a
GdmSession, itself (it has-a GdmSession), and it's unnecessarily generic;
it doesn't really have anything to do with "Welcome" or "Session"
itself. It managed a non-user GdmSession, spawned the process in the
correct environment (spawning a DBus daemon if need be) and made sure to
keep track of it until it died. I think "GdmLaunchEnvironment" is an
appropriate name for this.
https://bugzilla.gnome.org/show_bug.cgi?id=678057
|
| |
|
|
|
|
|
|
|
|
| |
commit 295d0bc42b11a9473a024b9cdca58bdd9197e905 made it so we
ship per-distro pam files upstream.
This commit updates those PAM files to be the latest version we
ship in Fedora.
https://bugzilla.gnome.org/show_bug.cgi?id=675085
|
|
|
The build system was inconsistent in its handling of pam files. The
multistack files had names ending in .pam, which we copied to an
unsuffixed file, and installed via pam_DATA. The non-multistack files
had unsuffixed filenames in the source, which we installed manually
via install-data-local.
Let's clean this up by naming every file with ".pam", and do the
rename when we put them in the install root. This is faster and
requires less makefile boilerplate to copy the files during the build
process.
Note: This also drops the previous crappy implementation of a
configuration management scheme where we only installed the files if
they didn't already exist. I'm not aware of anyone who actually uses
'make install' for gdm and cares about that semantic.
Finally, because all of these pam files are Red Hat specific, move
them to a separate pam-redhat directory, to ease the addition of a
future patch which adds PAM files for different systems.
https://bugzilla.gnome.org/show_bug.cgi?id=675085
|
