This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 pam-auth developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @MrFloya

Hi, I am using your pam-auth module, I have one problem, env vars set by a pam_module are not available in the process,

for example in pam_systemd, pam_misc_setenv(... "XDG_SESSION_ID" ...) I am never seeing this envvar in my process, but pam_systemd has called it.
Ref: https://github.com/systemd/systemd/blob/master/src/login/pam_systemd.c#L445

Any idea why this could happen? Or where I should search what is going wrong?

I´m having the next issue building pam from master branch:

cargo build  
   Compiling libc v0.2.103
   Compiling memchr v2.4.1
   Compiling cfg-if v1.0.0
   Compiling proc-macro2 v1.0.29
   Compiling version_check v0.9.3
   Compiling glob v0.3.0
   Compiling log v0.4.14
   Compiling unicode-xid v0.2.2
   Compiling quick-error v1.2.3
   Compiling unicode-width v0.1.9
   Compiling regex-syntax v0.6.25
   Compiling bitflags v1.3.2
   Compiling ansi_term v0.11.0
   Compiling strsim v0.8.0
   Compiling termcolor v1.1.2
   Compiling vec_map v0.8.2
   Compiling bindgen v0.55.1
   Compiling lazycell v1.3.0
   Compiling peeking_take_while v0.1.2
   Compiling lazy_static v1.4.0
   Compiling rustc-hash v1.1.0
   Compiling shlex v0.1.1
   Compiling cfg-if v0.1.10
   Compiling syn v1.0.78
   Compiling libloading v0.7.0
   Compiling textwrap v0.11.0
   Compiling humantime v1.3.0
   Compiling nom v5.1.2
   Compiling clang-sys v1.2.2
   Compiling aho-corasick v0.7.18
   Compiling quote v1.0.9
   Compiling atty v0.2.14
   Compiling which v3.1.1
   Compiling users v0.10.0
   Compiling clap v2.33.3
   Compiling regex v1.5.4
   Compiling cexpr v0.4.0
   Compiling env_logger v0.7.1
   Compiling pam-macros v0.0.2
   Compiling pam-sys v1.0.0-alpha3
   Compiling pam v0.7.0 (https://github.com/1wilkens/pam?branch=master#dc4fe9c9)
error[E0308]: mismatched types
 --> /home/ogranada/.cargo/git/checkouts/pam-b105b76664d251d7/dc4fe9c/src/enums.rs:8:1
  |
8 | #[pam_enum]
  | ^^^^^^^^^^^ expected `u32`, found `i32`
  |
  = note: this error originates in the attribute macro `pam_enum` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
  |
8 | #[pam_enum].try_into().unwrap()
  |

error[E0308]: mismatched types
   --> /home/ogranada/.cargo/git/checkouts/pam-b105b76664d251d7/dc4fe9c/src/enums.rs:119:1
    |
119 | #[pam_enum]
    | ^^^^^^^^^^^ expected `u32`, found `i32`
    |
    = note: this error originates in the attribute macro `pam_enum` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
119 | #[pam_enum].try_into().unwrap()
    |

error[E0308]: mismatched types
   --> /home/ogranada/.cargo/git/checkouts/pam-b105b76664d251d7/dc4fe9c/src/enums.rs:177:1
    |
177 | #[pam_enum]
    | ^^^^^^^^^^^ expected `u32`, found `i32`
    |
    = note: this error originates in the attribute macro `pam_enum` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
177 | #[pam_enum].try_into().unwrap()
    |

error[E0308]: mismatched types
   --> /home/ogranada/.cargo/git/checkouts/pam-b105b76664d251d7/dc4fe9c/src/enums.rs:226:1
    |
226 | #[pam_enum]
    | ^^^^^^^^^^^ expected `u32`, found `i32`
    |
    = note: this error originates in the attribute macro `pam_enum` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert an `i32` to a `u32` and panic if the converted value doesn't fit
    |
226 | #[pam_enum].try_into().unwrap()
    |

For more information about this error, try `rustc --explain E0308`.
error: could not compile `pam` due to 4 previous errors

Environment information:

OS: Linux debian 5.14.0-1-amd64 #1 SMP Debian 5.14.6-2 (2021-09-19) x86_64 GNU/Linux
CARGO: cargo 1.55.0 (32da73ab1 2021-08-23)
RUSTC: rustc 1.55.0 (c8dfcfe04 2021-09-06)

Package dependencies

[package]
name = "sample"
version = "0.1.0"

[dependencies]
# pam = "0.7.0"
pam = { git = "https://github.com/1wilkens/pam", branch = "master" }

Having the ability to authenticate against PAM is one thing. However you should also be able to implement your own pam modules using this API. Would be nice to have support for that.

I'm kind of new to rust but my understanding was that since these functions are wrapped (and therefore "safe") a segmentation fault shouldn't be able to happen.

Code:

let mut authenticator = pam_auth::Authenticator::new("sdm").expect("Unable to create authenticator.");
authenticator.set_credentials(user, password);
authenticator.authenticate().expect("Unable to authenticate user.");
trace!(log, "Authenticated user: {}", user);
authenticator.open_session().expect("Unable to open session."); // <--- Fault happens here
trace!(log, "Opened session");

Output:

Jan 31 20:14:32.806 TRCE Authenticated user: ayrton
[1]    8851 segmentation fault (core dumped)  cargo run

First of all thanks for making this library, it has made creating a Display Manager more enjoyable.

As you know it's kinda difficult to get any good information on how to make DMs, but I've managed to get to a point where I can comfortably use mine and I thought I'd share some of what I have learned. I made a fork of this project here with some changes I needed to get everything to work properly w.r.t. logind/systemd.

• pam_systemd.so - which is needed to get logind working - reads some PAM environment variables. So the user should have a way of setting the PAM vars propably. These also needs to be set before pam_open_session is called.
• As I understand it setting the process' actual environment variables could be confusing, especially if a single process is managing multiple PAM sessions. The better way imo is using Command::envs to set all of the PAM environment in the child process. For example like I have done in my DM.
• The PATH environment variable is probably better left to pam_env.so so that individual users or distributions can set the PATH variable in /etc/environment or ~/.pam_environment.

PAM produces a segmentation fault when compiled using musl libc.

Code:

let mut auth = pam::Authenticator::with_password("<pam_config_name>").unwrap();

This line produces a segmentation fault on Void GNU/Linux with musl.
uname -a output: Linux <hostname> 5.10.17_1 #1 SMP 1613600681 x86_64 GNU/Linux
pam crate version: 0.7.0

PamFlags are actually bitflags that can be passed in combination to the respective functions. As many functions support different subsets of flags, we should build a custom bitflags-enum for each function to ensure correct usage.

Currently the published package contains files irrelevant for the crate such as .travis.yml, .gitignore and examples. We should fix that by adding the following line to Cargo.toml.

include: [ "src/**/*", "LICENSE-*", "README.md", "CHANGELOG.md" ]

Hi,

First of all, thanks for writing this crate, it was a big help in making progress with PAM authentication in my project!

However there's one flaw that I can't get over without forking this crate, The handy into_pam_conv function which turns a native Conversation implementation into a conversation which can be passed on to start is currently not publicly exported.

This extremely limits the scope of what this crate can be used for since Client does not support setting advanced functionality such as set_item, acct_mgmt or chauthtok.

So…I'm kinda new to pam and I'm not entirely sure how some of this is supposed to work. When creating an Authenticator it takes a service name. Does this have to be one of these? https://docs.oracle.com/cd/E19683-01/816-4883/pam-34/index.html

I'm currently running into the problem that authenticate() fails and I'm not sure why (and not sure how to debug it)

Hi! Please create a new release tag and push it to crates.io. The latest version at this time, 0.7.0, is ancient and bears little resemblance to git master, which has received a ton of improvements and new features over the last 2.5 years.

My use case is that I'm implementing a screen locker where I am only interested in authenticating the user, not checking their account validity.

hello i tried building this last night so i can auto log into a plasmawayland session i have pam 0.8.0 and tried 0.7.0 as dependencies. and copy and pasted your command and added my user name etc but the build always fails with this
error[E0433]: failed to resolve: could not find Authenticator in pam
--> src/main.rs:11:25
|
11 | let mut auth = pam::Authenticator::with_password(service).unwrap();
| ^^^^^^^^^^^^^ could not find Authenticator in pam

For more information about this error, try rustc --explain E0433.
error: could not compile Gamescope (bin "Gamescope") due to 1 previous error

Hi @1wilkens !
Maybe you already know that, but in last commits you did to support the Pam Environment, there is something odd:
I have a local configuration with a krb5 pam lib, just there to add environment variable and test that.
During my login, the 'input' variable here,

from ptr 0x55a35d6bfdf0
current 0x55a35d6bfdf0
input [80, 65, 77, 95, 75, 82, 66, 53, 67, 67, 78, 65, 77, 69, 61, 47, 116, 109, 112, 47, 107, 114, 98, 53, 99, 99, 95, 112, 97, 109, 95, 107, 77, 120, 101, 50, 109]

In python, this translates to this:

>>> "".join(chr(x) for x in [80, 65, 77, 95, 75, 82, 66, 53, 67, 67, 78, 65, 77, 69, 61, 47, 116, 109, 112, 47, 107, 114, 98, 53, 99, 99, 95, 112, 97, 109, 95, 107, 77, 120, 101, 50, 109])
'PAM_KRB5CCNAME=/tmp/krb5cc_pam_kMxe2m'

But the actual content of the PamEnv is this:

[2022-06-28T15:52:59Z INFO auth_pam] Env [("PAM_KRB5CCNAME=", "tmp/krb5cc_pam_kMxe2m")]

So it seems there are two strange things here:

• shouldn't the variable name be "PAM_KRB5CCNAME" instead of "PAM_KRB5CCNAME"?
• same, the value should be "/tmp/krb5cc_pam_kMxe2m" instead of "tmp/krb5cc_pam_kMxe2m"?