On Thu, Mar 03, 2011 at 12:15:22PM -0800, Chris Wright wrote:

* David Miller (davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org) wrote:

quoted

From: Chris Wright <redacted>
Date: Thu, 3 Mar 2011 09:32:30 -0800

quoted

* Patrick McHardy (kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org) wrote:

quoted

commit 8ff259625f0ab295fa085b0718eed13093813fbc
Author: Patrick McHardy [off-list ref]
Date:   Thu Mar 3 10:17:31 2011 +0100

    netlink: kill eff_cap from struct netlink_skb_parms
    
    Netlink message processing in the kernel is synchronous these days,
    capabilities can be checked directly in security_netlink_recv() from
    the current process.
    
    Signed-off-by: Patrick McHardy [off-list ref]

Thanks for doing that Patrick.  I looked at this earlier and thought
there was still an async path, but I guess that's just to another
userspace process.

BTW, I think you missed a couple connector based callers:

drivers/staging/pohmelfs/config.c:      if (!cap_raised(nsp->eff_cap, CAP_SYS_AD
drivers/video/uvesafb.c:        if (!cap_raised(nsp->eff_cap, CAP_SYS_ADMIN))

Last time I checked, current() for connector based netlink message
consumers was the work queue that is used for connector.

So unless that changed, or my understanding is wrong, current_cap()
inside cn_queue_wrapper(), respectively the d->callback()
will not be the userland sender process' capabilities, but the work
queue capabilities.

If so, then this change introduces the possibility for normal users to
send privileged commands to connector based subsystems, even if they
may not be able to bind() to suitable sockets to receive any replies.

Am I missing something?

	Lars