savannah: cons.saver lacking privileges

[ossi]

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

Submitted by:	Oswald Buddenhagen <ossi>	Submitted on:	Mon 11 Jul 2005 04:35:25 PM UTC
Category:	Subshell	Severity:	3 - Normal
Status:	None Privacy:	Public
Assigned to:	None	Open/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. 

[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.

[zaytsev]

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?

[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.

[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.

[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.

[zaytsev]

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

[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".

[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.