The current function to activate core-dumps for vdr running setuid ist only working for kernel > 2.6.13 ( says the comment in vdr.c ). Actualy it is not working for 2.4.21 but it was easy an easy change, just replace prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) with prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)
If you need the switch with "2" ( what does "2" mean for >2.6.13 ??) It could do something like:
if (prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) < 0) { if (prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) < 0) { fprintf(stderr, "vdr: warning - cannot set dumpable: %s\n", strerror(errno)); // always non-fatal, and will not work with kernel < 2.6.13 } }
On Thu, 2006-02-16 at 20:01 +0100, leo2@pec.homeip.net wrote:
The current function to activate core-dumps for vdr running setuid ist only working for kernel > 2.6.13 ( says the comment in vdr.c ). Actualy it is not working for 2.4.21 but it was easy an easy change, just replace prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) with prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)
If you need the switch with "2" ( what does "2" mean for >2.6.13 ??)
It's "2" intentionally. "1" is a "no security" mode, "2" makes the core dumps readable by root only and applies additional checks. Like the comment says, "2" is available in kernels >= 2.6.13 only. For more info, see eg. the suid_dumpable description here: http://marc.theaimsgroup.com/?l=linux-kernel&m=109647550421014&w=2
Yes, the net effect is that the unmodified VDR 1.3.42 won't produce core dumps at all when not running as root with < 2.6.13 kernels, but IMO that's a reasonable tradeoff, at least as far as the default is concerned.
Ville Skyttä wrote:
On Thu, 2006-02-16 at 20:01 +0100, leo2@pec.homeip.net wrote:
The current function to activate core-dumps for vdr running setuid ist only working for kernel > 2.6.13 ( says the comment in vdr.c ). Actualy it is not working for 2.4.21 but it was easy an easy change, just replace prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) with prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)
If you need the switch with "2" ( what does "2" mean for >2.6.13 ??)
It's "2" intentionally. "1" is a "no security" mode, "2" makes the core dumps readable by root only and applies additional checks. Like the comment says, "2" is available in kernels >= 2.6.13 only. For more info, see eg. the suid_dumpable description here: http://marc.theaimsgroup.com/?l=linux-kernel&m=109647550421014&w=2
Yes, the net effect is that the unmodified VDR 1.3.42 won't produce core dumps at all when not running as root with < 2.6.13 kernels, but IMO that's a reasonable tradeoff, at least as far as the default is concerned.
So does this mean that '1' would work on older kernels?
Would it be feasible to use just '1' - after all, there's not much security about a VDR core file. Furthermore, it allows the normal user to immediately fire up the debugger with the core file, without having to first 'chown' the file (had this once, found it annoying).
So, if there are no complaints, I tend to make this line
if (prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) < 0) {
as suggested by the OP (who should send me a PM with his real name and email address if he wants to be mentioned in VDR/CONTRIBUTORS).
Klaus
On Sun, 2006-02-19 at 15:35 +0100, Klaus Schmidinger wrote:
Ville Skyttä wrote:
On Thu, 2006-02-16 at 20:01 +0100, leo2@pec.homeip.net wrote:
The current function to activate core-dumps for vdr running setuid ist only working for kernel > 2.6.13 ( says the comment in vdr.c ). Actualy it is not working for 2.4.21 but it was easy an easy change, just replace prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) with prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)
If you need the switch with "2" ( what does "2" mean for >2.6.13 ??)
It's "2" intentionally. "1" is a "no security" mode, "2" makes the core dumps readable by root only and applies additional checks. Like the comment says, "2" is available in kernels >= 2.6.13 only. For more info, see eg. the suid_dumpable description here: http://marc.theaimsgroup.com/?l=linux-kernel&m=109647550421014&w=2
Yes, the net effect is that the unmodified VDR 1.3.42 won't produce core dumps at all when not running as root with < 2.6.13 kernels, but IMO that's a reasonable tradeoff, at least as far as the default is concerned.
So does this mean that '1' would work on older kernels?
For some values of "work", yes ;)
Would it be feasible to use just '1' - after all, there's not much security about a VDR core file.
Well, the above link contains descriptions about what 1 means. The documentation says "... no security is applied. This is intended for system debugging situations only." whereas for 2 they say "... attempting to debug problems in a normal environment". Note that it's not only about the file permissions or the core file's contents. Only 2 opens the dump file with O_EXCL. Both 1 and 2 seem to use O_NOFOLLOW though.
Ville Skyttä wrote:
On Sun, 2006-02-19 at 15:35 +0100, Klaus Schmidinger wrote:
Ville Skyttä wrote:
On Thu, 2006-02-16 at 20:01 +0100, leo2@pec.homeip.net wrote:
The current function to activate core-dumps for vdr running setuid ist only working for kernel > 2.6.13 ( says the comment in vdr.c ). Actualy it is not working for 2.4.21 but it was easy an easy change, just replace prctl(PR_SET_DUMPABLE, 2, 0, 0, 0) with prctl(PR_SET_DUMPABLE, 1, 0, 0, 0)
If you need the switch with "2" ( what does "2" mean for >2.6.13 ??)
It's "2" intentionally. "1" is a "no security" mode, "2" makes the core dumps readable by root only and applies additional checks. Like the comment says, "2" is available in kernels >= 2.6.13 only. For more info, see eg. the suid_dumpable description here: http://marc.theaimsgroup.com/?l=linux-kernel&m=109647550421014&w=2
Yes, the net effect is that the unmodified VDR 1.3.42 won't produce core dumps at all when not running as root with < 2.6.13 kernels, but IMO that's a reasonable tradeoff, at least as far as the default is concerned.
So does this mean that '1' would work on older kernels?
For some values of "work", yes ;)
Would it be feasible to use just '1' - after all, there's not much security about a VDR core file.
Well, the above link contains descriptions about what 1 means. The documentation says "... no security is applied. This is intended for system debugging situations only." whereas for 2 they say "... attempting to debug problems in a normal environment". Note that it's not only about the file permissions or the core file's contents. Only 2 opens the dump file with O_EXCL. Both 1 and 2 seem to use O_NOFOLLOW though.
What is the way a core file is created if an application runs normally under a non-root user id (as in VDR before implementing the -u option)? If its the same as with the '1' option, then I'd say let's go for '1', since there's no difference to the previous behavior - or is there?
Klaus
-
Klaus Schmidinger -
leo2＠pec.homeip.net -
Ville Skyttä