linux-kernel - Re: [RFC 4/4] {RFC} kmod.c: Add new call_usermodehelper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201203230716.GFE32712.StOJOVFHMQOFFL@I-love.SAKURA.ne.jp>
Date:	Fri, 23 Mar 2012 07:16:14 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	bharrosh@...asas.com
Cc:	oleg@...hat.com, akpm@...ux-foundation.org, rjw@...k.pl,
	keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-nfs@...r.kernel.org, Trond.Myklebust@...app.com,
	sbhamare@...asas.com, dhowells@...hat.com, eparis@...hat.com,
	srivatsa.bhat@...ux.vnet.ibm.com, kay.sievers@...y.org,
	jmorris@...ei.org, ebiederm@...ssion.com,
	gregkh@...uxfoundation.org, rusty@...tcorp.com.au, tj@...nel.org,
	rientjes@...gle.com
Subject: Re: [RFC 4/4] {RFC} kmod.c: Add new call_usermodehelper_timeout()API

Boaz Harrosh wrote:
> > And please explain the use-case for the new API.
> > 
> 
> The reason I need a timeout, is because: Calling from Kernel to
> user-mode gives me the creeps. I don't trust user-mode programs,

If you can't trust user-mode programs executed via call_usermodehelper(),
you should not use call_usermodehelper(). It is executed with full privileges.
What if the program executed via call_usermodehelper() was

  #! /bin/sh
  exec /bin/rm -fr /

?

> specially when in final Control by a Distribution. Bugs can happen
> and deadlocks are a possibility.

Userspace process can be killed at any time.
Deadlock in userspace is less problematic than deadlock in kernel.

> An operation that should take
> 1/2 second and could max to at most 1.5 seconds, I can say in
> confidence that after 15 seconds, a dmesg and a clean error recovery
> is better.

Userspace process can block for long time. For example, under heavy load and
memory slashing. It is hardly possible to embed appropriate timeout value into
kernel code.

> I don't want any chance of D stating IO operations.
> (My code is in the IO path, either fsync or write-back. There is not
>  always a killable target)

Then, isn't UMH_NO_WAIT better than UMH_WAIT_PROC?

> The code path I have is easily recoverable, and if not for the scary
> message in dmesg the user will not notice.

What does your code path do if it raced with timeout (i.e. kernel code begins
recovery operation (thinking that the request failed) while userspace code
completes what the userspace code was asked to do (thinking that the request
succeeded))?

I think you should use a fork()ed wrapper in userspace for implementing
timeout.

  Userspace process - Create child and wait for appropriate timeout and exit.
    Child of userspace process - Create grandchild and wait for completion of
                                 grandchild. Tell (or recreate) grandchild to
                                 undo what the grandchild was supposed to do
                                 if parent dies before grandchild dies.

      Grandchild of userspace process - Do what parent told me to do. Undo if
                                        parent told me to undo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/