netdev - Re: [PATCH v2 net-next] af_unix: dont send SCM

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]

Date:	Mon, 19 Sep 2011 22:10:37 -0400
From:	Valdis.Kletnieks@...edu
To:	Tim Chen <tim.c.chen@...ux.intel.com>
Cc:	Eric Dumazet <eric.dumazet@...il.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

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.. ;)

Content of type "application/pgp-signature" skipped