FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-16-2010, 03:43 PM
Daniel J Walsh
 
Default Akonadi's unix sockets location

On 03/16/2010 12:29 PM, Colin Walters wrote:
> On Tue, Mar 16, 2010 at 12:16 PM, Daniel J Walsh<dwalsh@redhat.com> wrote:
>
>> PLEASE do not use /tmp for communications. Use /var/run if the service is
>> running as root, or can create a socket in /var/run.
>>
> In this case I believe it's a per-user service. In which case you
> don't have much of a choice, because you can't use $HOME or you'll be
> broken by the sysadmins that inflict NFS on users.
>
> The dbus session socket is currently in /tmp, but with a random name,
> and the session bus rejects connections by processes not matching its
> own uid.
>
Ok if they are from the same login session and same UID it is reasonable
to expect them to share /tmp.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-19-2010, 10:52 PM
Lennart Poettering
 
Default Akonadi's unix sockets location

On Tue, 16.03.10 14:52, Juha Tuomala (Juha.Tuomala@iki.fi) wrote:

>
> > [Connection]
> > SocketDirectory=/tmp/akonadi-myuser/
> >
> > into $HOME/.config/akonadi/akonadiserverrc
>
> How about setting that as default, away from $HOME that can be a NFS
> filesystem? I have had problems with it sometimes and that's
> probably not a rare case.

That is a security hole. Since /tmp knows no further access control an
evil user can just create dirs there for each and every single user on
the system. Those directories will then be owned by him, and all other
users will a) either completely fail to work or b) happily connect to
the evil user's services unless the software in question implements
two-way credential passing and verification (which I'd bet akonadi
doesn't do).

So either this is a DoS vulnerability or an even worse security hole.

So in short: don't do this. If you safely want to place a socket in
/tmp, you need to place it in a random dir, and then symlink (or
otherwise refer to it) from $HOME. Or better (as Colin suggested), just
use D-Bus to pass around the randomized socket path. (or even better:
use the new fd passing in D-Bus so that you don't need to socket path at
all)

Or even shorter: Unix sucks.

At last year's FOSS.in I did a talk about issues like this in Unix and
how to work around them in application and how incredibly hard it is to
get this right. One of those days I hope to find the time to write a
blog story about this.

I personally believe introducing a per-user /var/run (maybe as
/var/run/users/$USER which is created at login time) is cleanest way to
fix all of this.

> I can't imagine what harm that would cause to default under /tmp?

It's a shared namespace. As such it is a major source of
vulnerabitilities, especially if the developers didn't have this
particular use in mind.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-19-2010, 11:01 PM
Lennart Poettering
 
Default Akonadi's unix sockets location

On Tue, 16.03.10 08:38, Rex Dieter (rdieter@math.unl.edu) wrote:

>
> Juha Tuomala wrote:
>
> > https://bugs.kde.org/show_bug.cgi?id=179006#c5
> >> in the current version of Akonadi server you can specify a custom
> >> socket path by entering
> >>
> >> [Connection]
> >> SocketDirectory=/tmp/akonadi-myuser/
> >>
> >> into $HOME/.config/akonadi/akonadiserverrc
> >
> > How about setting that as default, away from $HOME that can be a NFS
> > filesystem?
>
> Indeed, a solution similar to kde's
> ~/.kde/socket-<hostname> => /tmp/ksocket-<username>
> symlink is likely needed here too.

If KDE really does this, it is really broken.

<hostname> is unsuitable for use cases like this, since on many
Fedora/RH systems it is just "localhost". And then very often it is
highly dynamic, sometimes even changing with DHCP.

If you want to identify a machine, use the D-Bus machine id. If you
don't want to link against the libdbus libraries (which you probably
should), then at least read /var/lib/dbus/machine-id and use that
(possibly with a fallback to the hostname, in case the admin is a nut).

The dbus machine id is the only suitable ID for usecases like this: it
is static, bound to the installation, and widely available.

In addition to this <username> is unsuitable for use cases like this
too, since it opens the door to DoS attacks by other users since they
can guess you socket path and create the socket and hence make it
impossible for you to use it.

If you want to do this properly, do something like this:

~/.kde/socket-<dbusid> → /tmp/ksocket-<random>/socket

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-19-2010, 11:10 PM
Lennart Poettering
 
Default Akonadi's unix sockets location

On Tue, 16.03.10 10:54, Matthias Clasen (mclasen@redhat.com) wrote:

> > > Symlinks are duct-tape, why not just set it to /tmp with
> > > global rc file?
> >
> > Sure, but still need to encode username into the filename (or randomize/uniq
> > it) somehow.
> >
>
> Any reason this cannot be an abstract socket ? Of course, then you have
> to check peer creds and figure out a way to communicate the socket name,
> but at least you don't have to worry about the usual races and
> permission problem you have with unix sockets.

Abstract sockets are not particularly useful for anything but system
services that are only started once, and very early during bootup. Why?
because they are not namespaced: every user can take every name he
wants. If a system service that is restartable or started late at bootup
needs a specific name then some evil user might already have taken it
away, creating a DoS situation.

As soon as a system is booted up to a level where non-system users can
login abstract namespace sockets must use randomized names, to avoid
these DoS issues. And a reference to those names would probably be have
to be written to the file system, so that it can be found by other
applications. And as soon as that happens, most advantages of sockets
that don't live in the fs hierarchy are gone.

Abstract sockets are a tool that is only really useful during early boot. For
everything else I don't think it really has any advantages over fs
sockets. However, they are harder to discover, which sucks.

In summary: unless you hack very low-level Linux-specific software
forget about abstract sockets.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-20-2010, 08:34 AM
Till Maas
 
Default Akonadi's unix sockets location

On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote:

> Ok if they are from the same login session and same UID it is reasonable
> to expect them to share /tmp.

Iirc, it would be more FHS compliant to use /var/tmp instead.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-20-2010, 09:34 AM
Lennart Poettering
 
Default Akonadi's unix sockets location

On Sat, 20.03.10 10:34, Till Maas (opensource@till.name) wrote:

> On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote:
>
> > Ok if they are from the same login session and same UID it is reasonable
> > to expect them to share /tmp.
>
> Iirc, it would be more FHS compliant to use /var/tmp instead.

No.

Unix sockets should definitely be cleaned up on reboot. Hence they
belong in /tmp better than in /var/tmp.

http://www.pathname.com/fhs/2.2/fhs-5.15.html

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-20-2010, 10:42 AM
Till Maas
 
Default Akonadi's unix sockets location

On Sat, Mar 20, 2010 at 11:34:58AM +0100, Lennart Poettering wrote:
> On Sat, 20.03.10 10:34, Till Maas (opensource@till.name) wrote:
>
> > On Tue, Mar 16, 2010 at 12:43:16PM -0400, Daniel J Walsh wrote:
> >
> > > Ok if they are from the same login session and same UID it is reasonable
> > > to expect them to share /tmp.
> >
> > Iirc, it would be more FHS compliant to use /var/tmp instead.
>
> No.
>
> Unix sockets should definitely be cleaned up on reboot. Hence they
> belong in /tmp better than in /var/tmp.

Why do they need to be cleaned up on reboot?

The problem with sharing files between applications using /tmp is this
specification:

http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
| Programs must not assume that any files or directories in /tmp are
| preserved between invocations of the program.

So in case there will be a file system for /tmp that automatically
removes files once they are not open anymore, abusing /tmp for this
will fail.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-20-2010, 10:48 AM
Lennart Poettering
 
Default Akonadi's unix sockets location

On Sat, 20.03.10 12:42, Till Maas (opensource@till.name) wrote:

> > Unix sockets should definitely be cleaned up on reboot. Hence they
> > belong in /tmp better than in /var/tmp.
>
> Why do they need to be cleaned up on reboot?

After the program that listened on them exited they are useless and
cannot be reused, they hence *must* be removed before another program
can listen on them again.

> The problem with sharing files between applications using /tmp is this
> specification:
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
> | Programs must not assume that any files or directories in /tmp are
> | preserved between invocations of the program.
>
> So in case there will be a file system for /tmp that automatically
> removes files once they are not open anymore, abusing /tmp for this
> will fail.

Uh? First of all, such an fs does not exist.

Secondly, as mentioned a unix socket is useless in the fs after the
program that listened on it exited, hence automatically deleting the
unix socket as soon as it exited would actually be a good idea.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-20-2010, 01:37 PM
Przemek Klosowski
 
Default Akonadi's unix sockets location

On 03/20/2010 07:48 AM, Lennart Poettering wrote:

> Secondly, as mentioned a unix socket is useless in the fs after the
> program that listened on it exited,

You mean in the context of a 'shared secret'-named sockets, right?
In general. a socket /tmp/socket can just sit there and be reused
by whatever programs fancy to open it for reading and/or writing. Or
have I misunderstood something in this discussion?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-20-2010, 01:54 PM
Lennart Poettering
 
Default Akonadi's unix sockets location

On Sat, 20.03.10 10:37, Przemek Klosowski (przemek.klosowski@nist.gov) wrote:

>
> On 03/20/2010 07:48 AM, Lennart Poettering wrote:
>
> > Secondly, as mentioned a unix socket is useless in the fs after the
> > program that listened on it exited,
>
> You mean in the context of a 'shared secret'-named sockets, right?
> In general. a socket /tmp/socket can just sit there and be reused
> by whatever programs fancy to open it for reading and/or writing. Or
> have I misunderstood something in this discussion?

No. Unix sockets cannot be reused. If the application that created the
socket via calling bind() for the path closed the socket, the socket
node is useless in the file system. Another bind() on it will return
ADDRINUSE and a connect() on it will return ECONNREFUSED. Only after it
was deleted it may be created anew with bind() and then be used again.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org