From: tim <tim.c.chen@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Valdis.Kletnieks@vt.edu, Tim Chen <tim.c.chen@linux.intel.com>,
David Miller <davem@davemloft.net>,
zheng.z.yan@intel.com, yanzheng@21cn.com, netdev@vger.kernel.org,
sfr@canb.auug.org.au, jirislaby@gmail.com, sedat.dilek@gmail.com,
alex.shi@intel.com
Subject: Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
Date: Thu, 22 Sep 2011 09:15:26 -0700 [thread overview]
Message-ID: <1316708126.1769.1.camel@schen9-lap> (raw)
In-Reply-To: <1316492170.2455.43.camel@edumazet-laptop>
On Tue, 2011-09-20 at 06:16 +0200, Eric Dumazet wrote:
> Le lundi 19 septembre 2011 à 22:10 -0400, Valdis.Kletnieks@vt.edu a
> écrit :
> > On Mon, 19 Sep 2011 14:39:58 PDT, Tim Chen said:
> > > Do we have to worry about the case where peer socket changes its flag
> > > to SOCK_PASSCRED while packets are in flight? If there isn't such
> > > pathological use case, the patch looks fine to me.
> >
> > I wouldn't think so - if you're sending a packet, and retroactively trying to
> > change the flag and expect it to work, your program is too ugly to live. After
> > all, if the scheduler had cut off your timeslice and scheduledthe receiving
> > process before you set the flag, that packet would be delivered and done with
> > anyhow, and no amount of wishing will set that flag on an already-delivered
> > packet.
> >
> > What *is* worth checking is that we DTRT if a process/thread is doing a send on
> > one CPU, and another process/thread with a shared file descriptor for that
> > socket is diddling the flag. But if we just define it as "atomic op to change
> > the flag and other observers get whatever value their CPU sees at that
> > instant", I'm OK with that too.. ;)
> >
>
> 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...
>
Should we reconsider the original approach of reducing the
pid/credential references, with your fixes to correct its flaws in the
streaming msg case?
Tim
next prev parent reply other threads:[~2011-09-22 16:13 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-04 5:44 [PATCH -next v2] unix stream: Fix use-after-free crashes Yan, Zheng
2011-09-04 7:12 ` Sedat Dilek
2011-09-04 8:23 ` Yan, Zheng
2011-09-04 15:50 ` Joe Perches
2011-09-06 16:39 ` Tim Chen
2011-09-06 16:25 ` Tim Chen
2011-09-06 17:40 ` Eric Dumazet
2011-09-06 18:50 ` Tim Chen
2011-09-06 19:01 ` Eric Dumazet
2011-09-06 19:33 ` Tim Chen
2011-09-06 19:43 ` Eric Dumazet
2011-09-06 19:59 ` Tim Chen
2011-09-06 20:19 ` Eric Dumazet
2011-09-06 22:08 ` Tim Chen
2011-09-07 2:35 ` Eric Dumazet
2011-09-06 23:09 ` Yan, Zheng
2011-09-07 2:55 ` Eric Dumazet
2011-09-16 23:35 ` David Miller
2011-09-16 16:50 ` Tim Chen
2011-09-19 7:57 ` Eric Dumazet
2011-09-07 4:36 ` Yan, Zheng
2011-09-07 5:08 ` Eric Dumazet
2011-09-07 5:20 ` Yan, Zheng
[not found] ` <1315381503.3400.85.camel@edumazet-laptop>
2011-09-07 12:01 ` Tim Chen
2011-09-07 20:12 ` Sedat Dilek
2011-09-07 20:30 ` Sedat Dilek
2011-09-07 14:37 ` Tim Chen
2011-09-08 0:27 ` Yan, Zheng
2011-09-07 21:06 ` Tim Chen
2011-09-07 21:15 ` Tim Chen
2011-09-08 6:21 ` Eric Dumazet
2011-09-08 4:18 ` Yan, Zheng
2011-09-08 5:59 ` Eric Dumazet
2011-09-08 6:22 ` Yan, Zheng
2011-09-08 7:11 ` Eric Dumazet
2011-09-08 7:23 ` Yan, Zheng
2011-09-08 7:33 ` Eric Dumazet
2011-09-08 9:59 ` Sedat Dilek
2011-09-08 13:21 ` [PATCH net-next v3] af_unix: " Eric Dumazet
2011-09-08 8:37 ` Tim Chen
2011-09-09 6:51 ` Eric Dumazet
2011-09-09 7:58 ` [PATCH net-next] af_unix: fix use after free in unix_stream_recvmsg() Eric Dumazet
2011-09-09 10:39 ` Tim Chen
2011-09-09 10:41 ` [PATCH net-next v3] af_unix: Fix use-after-free crashes Tim Chen
2011-09-08 7:56 ` [PATCH -next v2] unix stream: " Jiri Slaby
2011-09-08 8:43 ` Sedat Dilek
2011-09-08 7:02 ` Sedat Dilek
2011-09-07 21:26 ` Eric Dumazet
2011-09-08 13:28 ` Eric Dumazet
2011-09-08 9:24 ` Tim Chen
2011-09-09 5:06 ` [PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default Eric Dumazet
2011-09-12 19:15 ` Tim Chen
2011-09-19 1:07 ` David Miller
2011-09-19 4:28 ` Eric Dumazet
2011-09-19 15:02 ` Eric Dumazet
2011-09-19 15:52 ` [PATCH v2 " Eric Dumazet
2011-09-19 21:39 ` Tim Chen
2011-09-20 2:10 ` Valdis.Kletnieks
2011-09-20 4:16 ` Eric Dumazet
2011-09-22 16:15 ` tim [this message]
2011-11-28 13:23 ` Michal Schmidt
2011-11-28 13:38 ` Eric Dumazet
2011-09-28 17:30 ` David Miller
2011-09-08 10:05 ` [PATCH -next v2] unix stream: Fix use-after-free crashes Sedat Dilek
2011-09-08 8:50 ` Tim Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1316708126.1769.1.camel@schen9-lap \
--to=tim.c.chen@intel.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=alex.shi@intel.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jirislaby@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=sfr@canb.auug.org.au \
--cc=tim.c.chen@linux.intel.com \
--cc=yanzheng@21cn.com \
--cc=zheng.z.yan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).