> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/