Description of problem: On Mageia 1, a programme with "set-user-id" in its properties does not change the effective user-id when it is run. This problem has serious consequences when Mageia is used as a server (that is how I realised the problem) - for instance, when the backuppc utility is installed with lighttpd: lighty runs with user-uid apache, it launches backuppc with set-user-id in order to make backuppc run with its own uid and store files under that uid. This does not work - pratically a show-stopper for Mageia 1. Version-Release number of selected component (if applicable): Kernel: 2.6.38.1-server-1.mga (I have no idea, though, which component handles properties - all updates as off Sun 27.3. 20h00 installed). In case this has to do with security settings: I use out-of-the-box "standard" security level settings. How reproducible: whenever a suid programme is launched Steps to Reproduce: 1. Install the small demo perl program (see below) 2. chown <uid> sux.pl; chmod 04755 sux.pl 3. See the output which documents that the uid does not change (any <uid> different from the current one - e.g. guest - does for the demo ) This problem can be illustrated by a very short perl script (sux.pl) in a simple context (uid harms = 1000, uid backuppc = 200): <harms@pcjuergen ~/common> echo $USER harms <harms@pcjuergen ~/common> ls -l sux.pl -rwsr-xr-x 1 backuppc backuppc 56 Mar 27 20:01 sux.pl* <harms@pcjuergen ~/common> ./sux.pl real-uid = 1000 effective-uid = 1000 should give (and is on Mandriva 2010.1): real-uid = 1000 effective-uid = 200 ------------ Here is the perl script (sux.pl): ------------- #!/usr/bin/perl use strict; print stderr "real-uid = $< effective-uid = $>\n"; Reproducible: Steps to Reproduce:
I found a partial explanation: it appears that Mageia does not allow cgi (i.e. perl) scripts to be run with suid - other distros (including Mandriva) do. My sux.pl demo is such a script - an extremely simplified version of the wrapper script that launches backuppc when it is called by the http server. If I implement the same thing as a c-program that runs with setuid and prints the effective and the real script, it works correctly - also in Mageia. If my interpretaion is correct, this problem concerns all server applications that use cgi scripts that rely on suid: they do not run on Mageia as it is currently implemented. This problem seems to regularly pop up in various distros - it is documented as backuppc-related, but it is not: it is a general cgi problem - see https://bugzilla.redhat.com/show_bug.cgi?id=611009 (I will use the c-wrapper suggested in this thread as a workaround until the problem is fixed in Mageia).
perl-suid is dead in perl-5.12 c.f.: http://lists.mandriva.com/maintainers/2010-07/msg00097.php http://lists.mandriva.com/cooker/2010-07/msg00292.php
CC: (none) => jquelinSource RPM: kernel? => perlSeverity: major => normal
CC: jquelin => (none)Assignee: bugsquad => jquelin
Perlsuid does not come into question here (and is not used in backuppc on the Mandriva platform where Backuppc works) - this is a question of the strategy applied by a distro with respect to handling cgi scripts that need suid. Do a google for cgi wrapper and you will find lots of examples. For Mageia, the question is clear: Mageia has an announced policy that it wants (initially) be an upgrade from Mandriva 2010.1. Making life difficult for people who want to use standard packages such as backuppc does not come with that strategy. Personally, I have an easy to apply work-around - but personally I care how Mageia is perceived and seen in reviews.
it has nothing to do with cgi scripts. it really is related to the way perl suid scripts are now handled. from http://search.cpan.org/~rjbs/perl-5.12.3/pod/perlsec.pod#Security_Bugs ======== Beyond the obvious problems that stem from giving special privileges to systems as flexible as scripts, on many versions of Unix, set-id scripts are inherently insecure right from the start. The problem is a race condition in the kernel. Between the time the kernel opens the file to see which interpreter to run and when the (now-set-id) interpreter turns around and reopens the file to interpret it, the file in question may have changed, especially if you have symbolic links on your system. ======== and there were other problems at stake with setuid *scripts* - basically, perl 5 porters tried since perl beginnings to emulate this, but it was never fully secure. knowing this, they have decided to remove the perl-suid wrapper. it has been deprecated in 5.10.0, and removed in 5.12.0 - from perl5120delta: ======== suidperl suidperl is no longer part of Perl. It used to provide a mechanism to emulate setuid permission bits on systems that don't support it properly. ======== so, why does it work in mandriva 2010.1? because mdv2010.1 is shipping perl 5.10.x... try to upgrade your mandriva box to cooker (perl 5.12), and you will see that it doesn't work anymore. so, how to work around this? 2 different solutions: 1- either you write a c wrapper calling the perl script, and setuid this program 2- or you use sudo i recommend the 2nd solution, for different reasons: - it is universally deployed on servers - it is flexible (eg, it allows to be run without password) - no need to create one wrapper per script - it provides logging of who ran a command as root - it is actively maintained - it has a large user community i'm sorry if this doesn't please you - but that's an upstream decision, and i must confess that i understand why they did it.
Status: NEW => RESOLVEDResolution: (none) => INVALID
I perfectly understand - knowing the background (now - quite a lot of hours down the drain) I would have given the same reply. Googling, I have seen a third alternative that uses fastcgi, resp. spawns processes with the proper uid, based on using spawn-fcgi. But helas, it is a one-man initiative which I have not yet explored: http://users.k12system.com/mrwizard/backuppc-3.2.0-fastcgi.patch and http://sourceforge.net/mailarchive/forum.php?thread_name=11FB0CD6E5A337448CBF1AB26C00057D9AD1E3D5%40BOROMIR.win.k12system.com&forum_name=backuppc-devel Re solution (1), I have not managed to make the c-wrapper solution work as it is suggested in the redhad thread - I suspect that hiding a c-programme in a file that is meant to be a cgi script can create problems, there might also be a question of piping I/O channels, I need more time to dig into this. I will pursue this issue at my personal level - the quick and dirty solution for me is (on my server, lighttpd only supports backuppc and local xmarks) to use the same numerical uid for the user that runs lighttpd and the one running backuppc; that is not a solution, but allows to gain time. But I think that Mageia should not just let backuppc go down the drain - old backuppc users will have years of backup-files collected with backuppc which they cannot simply forget. Moreover backuppc remains a very valuable solution also for new users who need a flexible backup service on a multi-OS LAN. If I interpret my googling correctly, Fedora has a solution - even with perl 5.12. I suggest to close this bug under the current heading. Should another bug be opened clearly under the label "Backuppc does not work"? would be really nice if Mageia would have a documented approach that allows to use backuppc.
indeed, opening a bug specific for backuppc might be ok. knowing that the solution will not come from perl directly, but from a wrapper or whatever.
*** Bug 1736 has been marked as a duplicate of this bug. ***
CC: (none) => derekjenn