Bug 59297

Same thing happens to me with all 3 of my RH7.2 systems.  I wonder if this is
related to BUG # 54741?  It seems that before that bug fix was released, on a
stock 7.2 install, trying to run mc on a regular terminal would kill everything
for that login and bring me back to a login prompt.  Now, mc starts up, but any
time I ctrl-O it hangs.  Same thing happens if I run a command (like clear) from
within mc that tries to output to the regular screen.

> Same thing happens to me with all 3 of my RH7.2 systems.
This happens with *all* RH7.2 systems I guess...
The problem is that people submits this bug for mc package
instead of util-linux for some reasons and their reports
gets simply closed.

> I wonder if this is related to BUG # 54741?
No, this have nothing to do with telnet or tcsh.
But the bug 51833 is definitely that bug, but submitted
to a wrong place, hence closed.

> Now, mc starts up, but any time I ctrl-O it hangs.
Well, instead of waiting for the official resolution,
you can get an older util-linux package (ver 2.9 for ex),
manually extract a /bin/login from it and replace your
current /bin/login from util-linux-2.11 with it.
This will completely solve the problem.
Btw, mc is not the only casuality: also rhide (c/c++ ide)
suffers from that bug.

Hmmm, the plot thickens.  Check out this link for some more details on
this mc/cons.saver problem.

http://freshmeat.net/projects/midnightcommander/

Here's a little tidbit from the above link.

[;] Re: mc-4.5.5[23] hangs on startup (console)
by ZlatkO - Apr 17th 2001 14:42:19


> Does your cons.saver file has setuid bit enabled?

Thanks a lot for this hint! Seems like this was indeed the culprit, now it works
fine. :-)

Looks like someone quietly changed the "make install" routine to not 'chmod u+s
cons.saver' automatically after 4.5.51. Hint to the developers: a mention in the
ChangeLog/README would have been nice - sure, I found the appropriate comment in
src/cons.saver.c, but only after I knew what I had to look for.

Anyway, Life Is Good[tm] again - keep up the good works! 8-]

[reply] [top]

> Check out this link for some more details on
> this mc/cons.saver problem.
Actually I've already seen this "solution" in several places - not good.

>> Does your cons.saver file has setuid bit enabled?
> Thanks a lot for this hint! Seems like this was indeed the culprit, now it
works
> fine. :-)
Of course, if your cons.saver is suid-root, it would be able to access
/dev/vcsa even without having an ownership. But what to do with other progs?
rhide also broken, maybe some other progs as well. Make them all suid-root?
No, thanks:)

> Looks like someone quietly changed the "make install" routine to not 'chmod
u+s
> cons.saver' automatically after 4.5.51.
Looks like that person never really tried to figure out the problem:(
We have broken /bin/login and they complain to mc developers and set
suid bit to cons.saver (which can be also a security issue) - fine...
That was the reason why such a reports were just closed without any
explanations.
Not a big problem of course, we always can use an old /bin/login,
but still a bit annoying: according to an util-linux changelog, this was
done intentionally and by RH ingeneers (not by the official developers).

Hi,

You should just edit /etc/security/console.perms and add /dev/vcs* if you want
access to those devices.

I am under the impression that there are some bad things that users can do if
they have /dev/vcs* access, so I am not sure this makes a good thing to set as
the default, but since console.perms is part of the PAM package, I will leave
that decision up to nalin :)

hmm, login appears to have some ALLOW_VCS_USE support, so this isn't a PAM
issue, sorry..

The notice in the default util-linux config says:
# If ALLOW_VCS_USE is set to "yes", then login will chown /dev/vcsN
# to the current user, allowing her to make a screendump and do other
# nifty things on the console, but also allowing him to keep an open
# file descriptor after logging out to trick the next user.
ALLOW_VCS_USE=no

So it appears to be off for security reasons, as my gut recently told me.

I would suggest using the console.perms trick on your own system if you need
/dev/vcs* accessable.

> I would suggest using the console.perms trick on your own system if you need
> /dev/vcs* accessable.
It seems that you have missed a point: it is not me who needs
a /dev/vcs* accessable, it is a *widely-used* package from your
distro called mc (Midnight Commander) that doesn't work (simply
locks up) when /dev/vcsa is unaccessable. People tried to report
that bug directly for mc and it was closed. Now it is closed also
here, which means that you are OKey with the fact that you have a
very important package non-functional in the distro.
I can do with my system whatever I want, that's for sure, but this
bug (or feature) plaqued a lot of people, that was why I reported
it rather than silently work around it.
So, I am reopening that bug for now, but feel free to close it
again in case you really think it is not an issue anymore.

Your and my definitions of 'very important part' and 'non-functional' will continue to differ...