and how to install this patch?

On 7/10/06, Hans-Werner Hilse hilse@web.de wrote:

Hi,

On Mon, 10 Jul 2006 20:20:53 +0200 Sebastian Kemper sebastian_ml@gmx.net wrote:

...

I installed kernel 2.6.16.24 lately and get this warning when starting vdr. The same should happen with 2.6.17.4 since both share the same Changelog:

(Part of?) the according patch is this:

http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%...

...

So I was wondering if you could adapt vdr's dumpfile handling to the new situation and put the changes in vdr-1.4.2 in order to get rid of the warning, please.

That would be getting rid of dump file "handling" at all, I think, since PR_SET_DUMPABLE=1 is probably _not_ wanted since it reintroduces the problems why =2 was made before. So basically this means: No core dumps when s{u,g}id'ing.

A quick patch is appended.

-hwh

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

On Mon, 2006-07-10 at 21:00 +0200, Hans-Werner Hilse wrote:

That would be getting rid of dump file "handling" at all, I think, since PR_SET_DUMPABLE=1 is probably _not_ wanted since it reintroduces the problems why =2 was made before. So basically this means: No core dumps when s{u,g}id'ing.

I'm not disputing this fix per se, but it is highly unfortunate, as VDR crashes are often hard to reproduce. Running as root is not acceptable in many setups, and even temporarily switching between root and the normal dedicated user results in annoyances such as file ownership issues in addition to the uncertainty whether the crash condition can be reproduced in the first place. Being able to run as non-root and have "secure" core dumps (which actually turned out to be not that secure) enabled and subject to ulimit -c just as usual was convenient.

Would it be out of the question to add a command line option like --enable-insecure-core-dumps which when set and when run as non-root, would result in PR_SET_DUMPABLE=1, and otherwise no prctl() at all? This would get rid of some of the above difficulties.

On Sat, 2006-07-15 at 15:27 +0200, Hans-Werner Hilse wrote:

An updated patch is attached. It will probably need a bit of discussion if the command switch I've introduced is properly named (userdump), if the description fits and if the modus operandi is acceptable.

Hehe, I did a similar patch locally (attached), with slightly different naming and descriptions, but haven't tested it yet apart from that it compiles :)

By the way, is short-circuit if (...) evaluation (ie. for if (a && b), b is evaluated only if a is true) guaranteed in C++?

Hi,

On Sat, 15 Jul 2006 17:04:06 +0200 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:

...

(Part of?) the according patch is this: http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%...

Is this the final "fix" or just a quick hack to provide an immediate workaround? IMHO the actual problem should be fixed instead of removing a parameter option.

Correct. I don't think that anyone has made any decision in this case yet. I think a full revert of this feature would basically be a revert of this:

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...

I'm not convinced that it would be a good idea to restore the functionality of making core dumps when running as a non-priviledged user. A possibility would be to force core dumps into a preconfigured directory, changeable via a /proc entry.

Besides, I don't like the introduction of an extra VDR command line option for this. I suggest we either wait until there is a real fix in the kernel or, if no such fix comes and the '2' parameter to prctl() is actually voided, we go back to '1' and let the user control whether there should be a core dump via 'ulimit'.

I can't find that scenario very attractive, but that's probably just me. I don't see any good explanation of why on the one hand allow to drop privileges and on the other hand open that restriction by making the ability of doing core dumps the default setting. But I can certainly live with that, it's just a few lines in the code and a patch would be easy to maintain. And, after all, users who care for security can just start vdr as a non-root user.

-hwh