[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1322487533.2292.28.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Mon, 28 Nov 2011 14:38:53 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Michal Schmidt <mschmidt@...hat.com>
Cc: Valdis.Kletnieks@...edu, Tim Chen <tim.c.chen@...ux.intel.com>,
David Miller <davem@...emloft.net>, zheng.z.yan@...el.com,
yanzheng@...n.com, netdev@...r.kernel.org, sfr@...b.auug.org.au,
jirislaby@...il.com, sedat.dilek@...il.com, alex.shi@...el.com
Subject: Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by
default
Le lundi 28 novembre 2011 à 14:23 +0100, Michal Schmidt a écrit :
> On 09/20/2011 06:16 AM, Eric Dumazet wrote:
> > Note : The man page does states :
> >
> > "To receive a struct ucred message the SO_PASSCRED option must be
> > enabled on the socket."
> >
> > But it doesnt say if the SO_PASSCRED option must be enabled before the
> > sender sends its message, or before receiver attempts to read it.
> >
> > Once a message is queued on an unix socket, flipping SO_PASSCRED cant
> > change its content (adding or removing credentials), since sender might
> > already have disappeared.
> >
> > So current code includes credentials in all sent messages, just in case
> > receiver actually fetch credentials.
> >
> > There are probably programs that assume they can set SO_PASSCRED right
> > before calling recvmsg(). Are we taking risk to break them, or are we
> > gentle and provide a sysctl option to ease the transition, I dont
> > know...
>
> Such a case has just appeared:
> https://bugzilla.redhat.com/show_bug.cgi?id=757628
>
> systemd allows on-demand socket activation of services. It creates a
> listening socket without the SO_PASSCRED flag. When the first message
> arrives to the socket, systemd spawns the service and passes the
> socket's fd to it. The service sets SO_PASSCRED before actually
> receiving the message.
>
> I can fix that in systemd, but there may be more cases like this.
Yes, we were afraid of this.
Performance drop is really huge and deserves some fixes in userland...
People add features to kernel (in this case namespaces) without thinking
on performance regression. So poor guys like us have to "fix" things
later, in a reasonable way.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists