Ticket #22 (new defect) — at Version 11

Opened 11 years ago

Last modified 6 years ago

savannah: cons.saver lacking privileges

Reported by: ossi Owned by:
Priority: minor Milestone: Future Releases
Component: mc-core Version:
Keywords: Cc: zaytsev
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description (last modified by ossi) (diff)

Original: http://savannah.gnu.org/bugs/?13730

Submitted by:Oswald Buddenhagen <ossi>Submitted on:Mon 11 Jul 2005 04:35:25 PM UTC
Category:SubshellSeverity:3 - Normal
Status:None Privacy:Public
Assigned to:NoneOpen/Closed:Open
Release:current (CVS or snapshot)Operating System:GNU/Linux

Original submission:

this has been discussed to death already, but i've seen no viable 
solution so far, only hack suggestions and general paranoia.
the problem is, that "classical" 'configure && make && su -c make 
install' installations from upstream source have a non-working 
cons.saver, because it lacks access to /dev/vcsa?.
the preferred solution is having a vcsa group which /dev/vcsa? 
belong to and to which cons.saver is set-gid. however, there is no 
portable way across linux distros to accomplish this.
the pragmatic solution is just having cons.saver set-uid root and 
leaving potentially safer variants to distro-specific packages, 
like many other applications in the same situation do. after a 
security audit of the really small cons.saver source this variant 
should be perfectly applicable. 

Change History

comment:1 Changed 11 years ago by metux

hmm, IMHO the best idea is to issue a big-fat-warning on
make and in the Changelog and let the distros do their homework.

AFAIK every logged-in console user should get access to the
appropriate vcsa* device - that's what /bin/login+friends
have to handle.

comment:2 Changed 10 years ago by styx

  • Milestone set to 4.7

comment:3 Changed 10 years ago by angel_il

  • Milestone changed from 4.7 to future releases

Changed 9 years ago by ossi

for that matter, here is the patch i'm running with, uhm, like, forever. i can only re-iterate that the plain "make install" should *just work* and any modifications should be left to the distributors, not the other way round.

comment:4 Changed 9 years ago by ossi

  • Cc ossi@… added
  • severity set to no branch

comment:5 follow-up: ↓ 6 Changed 9 years ago by zaytsev

  • Cc zaytsev added

I think that it's distro's job to make sure that console users are having correct permissions by default, or, if they object, set the permissions they want to cons.saver.

FYI, in Debian /dev/vcsa* are root:tty and cons.saver is SGID tty. This has to be done explicitly, because SUID/SGID bits are automatically removed from make install root. Same goes for Redhat, Gentoo and other distributions.

The reason for this is quite simple: no one wants to have SUID/SGID binaries on their system, apart from a very small well controlled and audited subset of files. Making make install set SUID bit by default will not change anything for these distros, but make it easier for clueless users to mess their system up.

And by the way, what will happen if your patch is applied literally and make install is run as a user with say ~/opt prefix? Right, it will fail so set the permissions and the installation will abort.

I suggest a wontfix, others?

comment:6 in reply to: ↑ 5 Changed 9 years ago by ossi

Replying to zaytsev:

I think that it's distro's job

too bad that it isn't possible. there is no generic solution outside the mc package itself.

SUID/SGID bits are automatically removed from make install root.

yes, if you configure your cron jobs to break your system, then they will happily do it.

And by the way, what will happen if your patch is applied literally and make install is run as a user with say ~/opt prefix? Right, it will fail so set the permissions and the installation will abort.

feel free to prefix the commands with a dash, or put the whole thing in an automake conditional.

comment:7 Changed 9 years ago by zaytsev

Why wouldn't you just change the permissions for you instead of trying to get your patch in for everybody?

On Debian there's a sysadmin's tool called dpkg-statoverride that will override the permissions, defined by the packager and set them to those that the admin wants to have, so that it will survive package updates and manual chowns.

comment:8 Changed 9 years ago by ossi

don't you get it? this is about *upstream*. tar balls. that's all that the mc team as a whole officially releases. and that has to work out of the box, for everybody. currently, it doesn't. that simple.

comment:9 Changed 9 years ago by zaytsev

I get your point, but I don't agree with it. Paradoxically this actually happens.

comment:10 Changed 9 years ago by ossi

yes, but why? why are you concerned about the packaging? it can do any modifications necessary. it's the "make install" which upstream should make "just work".

comment:11 Changed 6 years ago by ossi

  • Cc ossi@… removed
  • Description modified (diff)
  • Branch state set to no branch
  • Reporter changed from slavazanko to ossi
Note: See TracTickets for help on using tickets.