Bug 59297 - mc locks on switching screen (Ctrl-o or any command) because cons.server need /dev/vcsa
mc locks on switching screen (Ctrl-o or any command) because cons.server need...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-04 15:25 EST by Stas Sergeev
Modified: 2007-04-18 12:39 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-08 15:34:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stas Sergeev 2002-02-04 15:25:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.17 i686)

Description of problem:
cons.server from mc needs an access to /dev/vcsa. Now it just locks up badly
because
/dev/vcs and /dev/vcsa are not being chowned at login.

Version-Release number of selected component (if applicable):
util-linux-2.11f-17
mc-4.5.51-36

How reproducible:
Always

Steps to Reproduce:
1. login as user (not root)
2. start mc
3. enter some commands
4. press Ctrl-o to see a command's output
5. press Ctrl-o again to return to mc
6. switch to another console and kill mc because it is already hanged...
7. ls -l /dev/vcsa

	

Actual Results:  mc locks up
/dev/vcsa is not owned by the logged user

Expected Results:  working mc
/dev/vcs and /dev/vcsa are owned by a logged user (same as /dev/tty)

Additional info:

chowning /dev/vcsa manually helps.
/dev/vcs and /dev/vcsa were chowned together with /dev/tty by /bin/login for
years, but apparently they are not anymore:( Expecting other breakages, I am
going to modify my startup scripts to work around the problem.
Comment 1 Don Himelrick 2002-03-03 11:55:04 EST
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.
Comment 2 Stas Sergeev 2002-03-03 14:29:43 EST
> 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.
Comment 3 Don Himelrick 2002-03-04 14:28:11 EST
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]

Comment 4 Stas Sergeev 2002-03-04 15:40:38 EST
> 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).
Comment 5 Elliot Lee 2002-03-08 14:09:55 EST
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 :)
Comment 6 Elliot Lee 2002-03-08 14:14:18 EST
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.
Comment 7 Stas Sergeev 2002-03-08 15:34:34 EST
> 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.
Comment 8 Elliot Lee 2002-06-24 09:28:01 EDT
Your and my definitions of 'very important part' and 'non-functional' will continue to differ...

Note You need to log in before you can comment on or make changes to this bug.