[colug-432] Okay, I've got to be doing something stupid... any thoughts on what?

[Jon Miller]

William Yang writes:

> On 07/10/2015 05:20 PM, R P Herrold wrote:> On Fri, 10 Jul 2015, William
> Yang wrote:
>>
>>> login prompt.  There's some kind of error message that looks like it may
>>> say permission denied, but the screen refreshes and clears too quickly for
>>> me to really understand it.  I tried for 90 minutes to get it to happen in
>>> a way I could capture it, without success.
>>
>> SElinux comes to mind and perl's access to a file may be being
>> blocked.  Check:
>> 	/var/log/audit/audit.log
>>
>> -- Russ herrold
>>
>
> Thanks, Russ!
>
> That nudge was enough for me to get to a root cause and suggested good
> solutions.
>
> There was nothing in the audit log except a bunch of success reports from
> 'login'... but that go me to thinking about login processes.  OpenSSH does
> not invoke login unless you explicitly tell it to, and by default invokes
> shells itself.  So, maybe that was why ssh logins worked, but login didn't....
>
> When I set sshd to 'UseLogin yes' and tried to log in....
>
> $ ssh testmenu at centos7
> testmenu at centos7's password:
> login: Permission denied
> Connection to centos7 closed.
>
> The audit log didn't show failures except for password typos at
> authentication....
>
> However, exactly what was happening wasn't clear.  My script is a text file
> beginning with a traditional '#!/usr/bin/perl' directive... that's a
> directive telling the parent how to interpret the rest of the incoming data
> stream for execution.  It occurred to me that maybe that string wasn't
> getting parsed.
>
> So, I checked the sources for /bin/login (util-linux-2.23.2/login-utils)
> and, sure enough, I didn't see identify a shell directive... so /bin/login
> didn't know how to interpret the data, causing the login failure!
>
> There are a bunch of solutions to this.  I already had a workaround (using
> a restricted shell and building menu invocation into the user's profile)...
> but that seemed kludgy to me because it's creating more to support.
>
> I thought of two other directions for solutions:
>
> 1. Write a C wrapper that pretty much just exec's perl with the script.
> Not ridiculous, but requires another object (making it as kludgy as the
> restricted shell solution, though probably a more secure approach) and
> still requires secondary development, debug, and maintenance.
>
> 2. Change the user's shell to "/usr/bin/perl [script name]" -- which was
> inspired from reading the sources of /bin/login, which discusses using
> shell scripts and the behavior when there's a space in the shell
> definition.  Slightly changes invocation (/bin/sh execs /usr/bin/perl which
> then interprets the script) but doesn't have a substantial impact on
> performance and can be maintaned with a README file I only have to write
> once.  The downside is that I really don't know how portable that solution
> is.
>
> You can probably guess which one I did.  I did note the downsides in the
> README in case we ever change underlying platforms.
>
> 	-Bill

Not sure all what you're trying to achieve with your Perl script, but perhaps
another solution could be to leverage PAM to achieve the extra, up-front
execution that you are looking for and avoid the login/ssh differences,
etc. Take a look at pam_exec and/or even writing your own pam module.

-- 
Jon Miller