> Now I know why I had such trouble getting setuid programs to work > on Linux. > > My understanding of Greg and Jeroen's explanations is that the kernel > ignores whether an interpreted program has the setuid bit set -- it > just executes the interpreter given after the #!, passing the full > pathname of the file containing interpreted program as the first argument. > If the interpreter wants to then go ahead and look at the setuid or > setgid bits on the file it was given as the first argument, the way > perl and suidperl do, that's the interpreter's business.
This has not always been like that. I looked at the issue of suid/sgid shell scripts before and there were some patches (in times of 2.0.x kernles) to enable it. BUT this functionality is not present for a good reason: shell scripts are inherently unsafe! I'd say that for a SUID/SGID *shell* script taking any untrusted parameters is serious security hazard. It is not an issue for game wrappers that basically just start the game passing to it all parameters as they were given by the caller. But writing anything more advanced in suid/sgid shell is just asking for serious (security) troubles. In setid-wrapper package there should be *BIG* warning about it, possibly in more than one place. > >Should we > >pass the concept by Debian Security first? > > I like Greg Prokopski's idea of writing the code first, It doesn't seem big enough to be worth discussing w/o code in place first. If you were to actually write such universal wrapper, then I think it'd make sense to allow for suids too. So the config file would consist of lines more less like that: /usr/bin/my_game .games /usr/lib/my_game/bin/game /usr/bin/my_util root.root /usr/lib/my_util/util BTW: your wrapper should also check whether the user who claims to have ran your wrapper actually has *execution rights* to it! One could play an ld.so trick and execute it (AFAIR). There's probably more security concerns. You should see perl-suid sources. Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]