From: Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: Michael Bacarella <mbac@nyct.net>, linux-kernel@vger.kernel.org
Subject: Re: getpeereid() for Linux
Date: 05 Sep 2001 18:36:01 +0200 [thread overview]
Message-ID: <tgsne1tx1q.fsf@mercury.rus.uni-stuttgart.de> (raw)
In-Reply-To: <200109051619.LAA58471@tomcat.admin.navo.hpc.mil>
In-Reply-To: <200109051619.LAA58471@tomcat.admin.navo.hpc.mil> (Jesse Pollard's message of "Wed, 5 Sep 2001 11:19:07 -0500 (CDT)")
Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:
> > I need the credentials only for local connections, though. This is
> > technically possible. A userspace implementation partially cloning
> > ident seems to be a possible approach.
>
> It won't be reliable.
I don't think so. At least the
> Even the documentation for ident (at least the version I looked at a
> while ago, might be different now, but I don't think so) says that
> the data returned is not reliable. (even fuser doesn't always get
> this right when trying to identify processes with open sockets).
The trick is not to identify processes.
> Part of the problem is that TCP sockets don't carry the same information
> that domain sockets have (could be partially wrong here, it just may not
> be filled in since the source of the data can't supply it).
Fortunately, they do carry the necessary data in the Linux kernel.
Otherwise, you would have a pretty hard time to implement the
netfilter owner match rules.
My current approach is the following: fstat() the socket to get its
inode, look up the inode in /proc/net/tcp to get a (local, remote)
pair. Swap the pair and search /proc/net/tcp again to get the UID the
other end. No race condition is possible because the kernel may not
create a new (remote, local) pair because we hold open the (local,
remote) socket, so even a SO_REUSEADDR will not do the trick.
> The other part is that it depends on what allocated the socket.
Yes, that might be a problem, but this affects netfilter as well. The
kernel structure records the effective UID of the process at the time
of the creation of the socket. It might have changed afterwards.
> Ownership is established at socket allocation time, and the socket
> can be passed to a totally different user. Identity of the user of
> the socket is therefore lost.
Hmm, you can always forward connections, so this isn't a problem. If
some decides to give his credentials away, he is free to do so. ;-)
--
Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
next prev parent reply other threads:[~2001-09-05 16:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-05 16:19 Jesse Pollard
2001-09-05 16:36 ` Florian Weimer [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-09-05 15:51 Jesse Pollard
2001-09-05 15:53 ` Florian Weimer
2001-09-05 20:26 ` H. Peter Anvin
[not found] <tgsne23sou.fsf@mercury.rus.uni-stuttgart.de.suse.lists.linux.kernel>
2001-09-05 9:52 ` Andi Kleen
2001-09-05 10:05 ` Florian Weimer
2001-09-05 10:48 ` Andi Kleen
2001-09-05 10:56 ` Florian Weimer
2001-09-05 9:14 Florian Weimer
2001-09-05 13:38 ` Michael Bacarella
2001-09-05 14:35 ` Florian Weimer
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=tgsne1tx1q.fsf@mercury.rus.uni-stuttgart.de \
--to=florian.weimer@rus.uni-stuttgart.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mbac@nyct.net \
--cc=pollard@tomcat.admin.navo.hpc.mil \
/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
all inboxes | Powered by JetHome®