Messages in this thread | | | Date | Sun, 20 Aug 2006 21:17:22 +0200 | From | Willy Tarreau <> | Subject | Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits |
| |
On Sun, Aug 20, 2006 at 08:33:27PM +0100, Alan Cox wrote: > Ar Sul, 2006-08-20 am 21:01 +0200, ysgrifennodd Willy Tarreau: > > 2.4 has no printk_ratelimit() function and I'm not sure it's worth adding > > one for only this user. One could argue that once it's implemented, we can > > uncomment some other warnings that are currently disabled due to lack of > > ratelimit. > > Agreed. But if it isnt ratelimited then people will be able to use it > flush other "interesting" log messages out of existance... > > > > > In this special case (set*uid), the only reason we might fail is because > > kmem_cache_alloc(uid_cachep, SLAB_KERNEL) would return NULL. Do you think > > it could intentionnally be tricked into failing, or that under OOM we might > > bother about the excess of messages ? > > > > If so I can backport the printk_ratelimit() function, I would just like an > > advice on this. > > If there are multiple potential users then a backport might be sensible
Ok, I will proceed that way then. I see at least two places in binfmt_elf :
631 if ((interpreter_type & INTERPRETER_ELF) && 632 interpreter_type != INTERPRETER_ELF) { 633 // FIXME - ratelimit this before re-enabling 634 // printk(KERN_WARNING "ELF: Ambiguous type, using ELF\n"); 635 interpreter_type = INTERPRETER_ELF; 636 }
824 if (BAD_ADDR(elf_entry)) { 825 printk(KERN_ERR "Unable to load interpreter %.128s\n", 826 elf_interpreter); 827 force_sig(SIGSEGV, current); 828 retval = IS_ERR((void *)elf_entry) ? PTR_ERR((void *)elf_entry) : -ENOEXEC; 829 goto out_free_dentry; 830 }
The first one might be interesting, while the second one should definitely be ratelimited or removed.
Thanks, willy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |