savannah: cons.saver lacking privileges

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/22
Reporter	ossi (@ossilator)
Mentions	zaytsev (@zyv)

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. 

Note

Original attachments:

• 0001-install-cons.saver-setuid-root.patch (raw) by ossi (@ossilator) on Oct 8, 2020 at 19:28 UTC

[mc-butler]

Changed by metux (@metux) on Dec 26, 2008 at 21:34 UTC (comment 1)

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.

[mc-butler]

Changed by styx (@styx) on Feb 23, 2009 at 19:12 UTC (comment 2)

• Milestone set to 4.7

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Jun 17, 2009 at 14:54 UTC (comment 3)

• Milestone changed from 4.7 to future releases

[mc-butler]

Changed by ossi (@ossilator) on Jul 11, 2010 at 11:30 UTC (comment 4)

• Cc set to ossi@….org
• Severity set to no branch

[mc-butler]

Changed by zaytsev (@zyv) on Jul 11, 2010 at 13:04 UTC (comment 5)

• Cc changed from ossi@….org to ossi@….org, 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?

[mc-butler]

Changed by ossi (@ossilator) on Jul 11, 2010 at 13:24 UTC (comment 5.6)

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.

[mc-butler]

Changed by zaytsev (@zyv) on Jul 11, 2010 at 13:27 UTC (comment 7)

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.

[mc-butler]

Changed by ossi (@ossilator) on Jul 11, 2010 at 13:33 UTC (comment 8)

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.

[mc-butler]

Changed by zaytsev (@zyv) on Jul 11, 2010 at 15:12 UTC (comment 9)

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

[mc-butler]

Changed by ossi (@ossilator) on Jul 11, 2010 at 15:51 UTC (comment 10)

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

[mc-butler]

Changed by ossi (@ossilator) on Jan 11, 2014 at 15:48 UTC (comment 11)

• Reporter changed from slavazanko to ossi
• Cc changed from ossi@….org, zaytsev to zaytsev
• Description edited
• Branch state set to no branch

[mc-butler]

Changed by ossi (@ossilator) on Oct 8, 2020 at 19:28 UTC

• Attachment 0001-install-cons.saver-setuid-root.patch (raw) added

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.