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

[William Yang]

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


-- 
William Yang
wyang at gcfn.net