On 24.3.2015 14:54, Thorsten Kukuk wrote:
Hi,
after cleaning up the ticket system and fixes the minor documentation
issues, we still have some open tickets:
#9 [PATCH] Allow pam_lastlog to write to utmp as an option
=> I suggest to reject that. That's more academic and not needed.
Yes, I agree.
#20 compilation warnings
=> I suggest to ignore the last warnings
Yes, I agree.
#24 [PATCH] pam_env: Expand @{HOME} and @{SHELL}
=> Any opinion about this? If you all think we should do it, I would look
at the patch.
I think this would be useful feature so +1 to incorporating the patch.
#26 Use more fail safe method of indicating success from unix_chkpwd
=> Tomas, will you look at this?
It was on my todo list for quite long, but I am too busy with other
things currently. But please keep it open.
#28 Allow module to put the tty to echo off mode via conversation
function
=> Any volunteer for this one?
Do all of you agree that this would be something desirable to implement?
#29 pam_env documentation update
=> the patch in this form is unuseable, I think most docu is
harder to understand then currently. But some changes could
be usefull.
Yes, it needs a review.
#30 Support for skipping to labels instead of numbers of rules.
=> I would suggest to reject this. Or any volunteer to implement this?
But I think this would not make the whole stuff better.
I still think that either labels or some kind of substacking inside a
single file would be useful. The problem that they are trying to solve
is genuine.
#34 support alternative "vendor configuration" files as
fallback to /etc
=> This are two bugs in one
1. I disagree that modules should ignore that they are used but not
configured. This will only be confusing and a source for errors.
2. I don't like this /usr/lib/pam.d/ concept.
I agree that the 1st change is very debatable.
On the other hand the /usr/lib/pam.d/ concept follows the same concept
that was introduced by systemd and it was followed by too many other
system tools that we probably cannot completely ignore it. I think it
really solves some problems but also unfortunately introduces different
ones. Adding the support should be quite harmless though.
#37 Wrong SELinux AV used in pam_rootok?
=> Tomas, do you know more about this?
I am checking with SElinux developers.
#39 [PATCH] doc: pam_access docs are incomplete/misleading
=> the patch looks Ok for me.
Yes.
#40 expose_auth doesnt work with pam_exec when user does not exist
=> I don't understand why this should not work by looking at the code.
Looks more like a stacking issue, need to dig deeper into this.
I think this needs more info.
Regards,
Tomas Mraz