From: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
Alexey Dobriyan
<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH] c/r: Add AF_UNIX support (v3)
Date: Tue, 07 Jul 2009 07:52:30 -0700 [thread overview]
Message-ID: <87prccsfyp.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: <4A527EB8.4060201-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> (Oren Laadan's message of "Mon\, 06 Jul 2009 18\:46\:16 -0400")
OL> But there are two cases: if you are CAP_NET_ADMIN you are allowed
OL> to go beyond that limit. So you need to add that test too.
Okay, fair enough.
OL> And in general, this helps to keep the checks - be it security,
OL> resource limits, or whatever - in one place, instead of having to
OL> duplicate code and, more importantly, risk getting out of sync
OL> with the original checks (e.g., if sock_setsockopt changes).
But sock_setsockopt() will also set the userlocks flag saying that
you've specified the buffer size. At the point at which I currently
restore the buffers, we've already restored the value specified in the
checkpoint stream, so we'd need to re-reset it as a special case after
the call to sock_setsockopt(). Further, to get the "override" case,
you have to call it with SO_RCVBUFFORCE which fails if you're not
CAP_SYS_ADMIN. So, do we try force, then if it fails try SO_RCVBUF,
then if it fails actually fail? Since sock_setsockopt() doubles the
buffer size we get it, do we cut the value we want in half before
passing it in?
Doing all that seems like an abuse of sock_setsockopt() to me when the
alternative is to check CAP_SYS_ADMIN and set the buffer size.
OL> But we do care, because it is necessary to do the unlink() after
OL> the bind(), like you do for listening sockets, for this scenario:
OL> s = socket()
OL> bind(s, pathname)
OL> unlink(pathname)
OL> <---- checkpoint/restart
OL> r = socket()
OL> bind(r, pathname)
OL> The second bind() will succeed on the original system, but will
OL> fail on the restarted system, unless you do that.
Not if we don't actually call bind(s) in the unlinked case. What I
meant in my previous response is: if we're unlinked, then just fake
the bind actions but don't actually do the bind()..unlink(). We
already went over the case where we might unlink() a valid socket
depending on the order, right?
OL> BTW, I just looked again at the code, and I'm concerned about:
OL> + if (!un->linked) {
OL> + struct sockaddr_un *sun =
OL> + (struct sockaddr_un *)&h->laddr;
OL> + ret = sock_unix_unlink(sun->sun_path);
OL> + }
OL> You need to verify that the address is not abstract, because I'm
OL> not sure what sock_unix_unlink() would do given the empty
OL> string. Usually this is filtered higher in the VFS (getname).
Yep, but luckily that's gone with my recent changes to fake the bind()
for unlinked sockets instead of actually doing the unlink() :)
--
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
next prev parent reply other threads:[~2009-07-07 14:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 15:55 [PATCH] c/r: Add AF_UNIX support (v3) Dan Smith
[not found] ` <1245167716-28906-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-06-25 2:30 ` Oren Laadan
2009-06-29 17:29 ` Dan Smith
[not found] ` <871vp3x81s.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-07-02 9:15 ` Oren Laadan
2009-07-06 18:31 ` Dan Smith
[not found] ` <87y6r1slxz.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-07-06 19:06 ` Oren Laadan
[not found] ` <4A524B40.4040600-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-07-06 22:12 ` Dan Smith
[not found] ` <87tz1psbpq.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-07-06 22:46 ` Oren Laadan
[not found] ` <4A527EB8.4060201-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-07-07 14:52 ` Dan Smith [this message]
[not found] ` <87prccsfyp.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-07-07 15:15 ` Oren Laadan
[not found] ` <Pine.LNX.4.64.0907071102341.24765-CXF6herHY6ykSYb+qCZC/1i27PF6R63G9nwVQlTi/Pw@public.gmane.org>
2009-07-07 15:24 ` Dan Smith
2009-07-07 15:33 ` Oren Laadan
2009-07-07 15:36 ` Dan Smith
[not found] ` <87ab3gsdwx.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-07-07 15:48 ` Oren Laadan
[not found] ` <4A536E44.6050601-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-07-07 16:04 ` Dan Smith
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=87prccsfyp.fsf@caffeine.danplanet.com \
--to=danms-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.