Re: GPG homedir path length limit

2017-02-17 Thread Daniel Kahn Gillmor 
On Fri 2017-02-17 04:42:14 -0500, Justus Winter wrote:
> Well, I tested it on all systems I had access to at that time.  I could
> have written a small test program, and asked people to run it on systems
> we don't have access to.  But we never got to that point :(

That would be a way to advance this conversation, i think :)

However, path length may only be one concern.  What about other
scenarios, like trying to operate with a read-only $GNUPGHOME ?  Is that
something we want to support?  What about a $GNUPGHOME that resides on a
network-mount drive, or a filesystem that doesn't support unix-domain
sockets?

>> But if you ever use getsockname (e.g. common/sysutils.c and
>> dirmngr/dns.c), the long socket path names are bound to fail on *any*
>> system, right?
>
> Yes.  And iirc I went over why we use getsockname and figured that we
> could do away with them.

but they're still there!  if they're not necessary, we should remove
them.  useful diffs with more -'s than +'s are very nice contributions
to any complex software project :)

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-17 Thread Justus Winter 
Daniel Kahn Gillmor  writes:

> On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote:
>> That is still wrong.  The length of the path of the socket is not
>> limited in any way, the length of the path passed to connect is.
>
> this is a clever approach to *connect* to such a socket,

Yes.

> on some systems.

Well, I tested it on all systems I had access to at that time.  I could
have written a small test program, and asked people to run it on systems
we don't have access to.  But we never got to that point :(

> But if you ever use getsockname (e.g. common/sysutils.c and
> dirmngr/dns.c), the long socket path names are bound to fail on *any*
> system, right?

Yes.  And iirc I went over why we use getsockname and figured that we
could do away with them.


Justus


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-16 Thread Daniel Kahn Gillmor 
On Thu 2017-02-16 11:51:07 -0500, Werner Koch wrote:
> So that the /var/run/user/ directory is not cluttered with many
> directories.  Setting a different GNUPGHOME is an exception and thus it
> is fine to require an explicit creation.  Remember that not /var/run
> does not need to be a temporary directort - there is more than Linux in
> this world.

If it's an exception, it's infrequent.  So by definition, we won't be
cluttering /run/user/$(id -u)/gnupg/ with many directories.

If we clean up the directories automatically as i recommended when the
daemons terminate, it won't leave a cluttered residue.

The one common work pattern that this misses is this one:

 * create a temporary GNUPGHOME for experimentation
 * when done, do:   rm -rf "$GNUGHOME"

Without the socketdir creation, the daemons will work as long the path
is short enough, and they terminate cleanly when the temporary homedir
is destroyed.

With the socketdir creation, the daemons will work regardless of the
path length, but they won't terminate cleanly if the temporary homedir
is destroyed.  That would be unfortunate.

So my current proposal for GNU/Linux systems for daemons like gpg-agent
and dirmngr when using a non-standard $GNUPGHOME is:

  * daemons create the ephemeral socketdir automatically if possible.
  * clients try the ephemeral socketdir first, then fall back to
in-$GNUPGHOME sockets (i think this is already the case).
  * daemons watch the $GNUPGHOME with inotify, and auto-terminate if the
$GNUPGHOME itself is destroyed.
  * daemons try to rmdir() on the ephemeral socketdir on termination,
failing quietly on ENOTEMPTY.

I've documented this as a bug report at:

   https://bugs.gnupg.org/gnupg/issue2964

>> I personally like the simplicity and uniformity of "if /run/user/$(id
>> -u)/ exists and is writable, then we will use it for the socketdir."
>
> That is non-portable.

What's non-portable about it?  If it's not possible to create the
directory, we don't create it, and fall back to trying locally.  if it
is possible, we do create it and use it.

This thread should probably move over to gnupg-devel at some point, i
guess...

   --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-16 Thread Daniel Kahn Gillmor 
On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote:
> That is still wrong.  The length of the path of the socket is not
> limited in any way, the length of the path passed to connect is.

this is a clever approach to *connect* to such a socket, on some
systems.

But if you ever use getsockname (e.g. common/sysutils.c and
dirmngr/dns.c), the long socket path names are bound to fail on *any*
system, right?

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-16 Thread Werner Koch 
On Wed, 15 Feb 2017 18:12, d...@fifthhorseman.net said:

> Why does this need to be created manually?  Why not try to create it if
> possible the first time there's a chance to use it, no matter what?

So that the /var/run/user/ directory is not cluttered with many
directories.  Setting a different GNUPGHOME is an exception and thus it
is fine to require an explicit creation.  Remember that not /var/run
does not need to be a temporary directort - there is more than Linux in
this world.

> I personally like the simplicity and uniformity of "if /run/user/$(id
> -u)/ exists and is writable, then we will use it for the socketdir."

That is non-portable.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpxDgUNrwL5v.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-16 Thread Werner Koch 
On Thu, 16 Feb 2017 10:12, jus...@g10code.com said:

> That is still wrong.  The length of the path of the socket is not
> limited in any way, the length of the path passed to connect is.

That is your experience from Linux but that is not in general true.  The
maximum length of a file length is limited and thus is the length of the
socket.  And that length limit depends on the file system

> I still believe we could have/should have made it just work with any
> home directory.

The reason why we switched to /var/run is to allow the use of remotely
mounted home directories without the redirect-file hack.  That this also
fixes build problems is merely a side effect.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp6TqmZ4h2XC.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-16 Thread Justus Winter 
Daniel Kahn Gillmor  writes:

> [ Unknown signature status ]
> Hi all--
>
> sorry for the late followup on this thread:
>
> On Mon 2017-01-16 14:16:28 -0500, Werner Koch wrote:
>> On Sun, 15 Jan 2017 00:39, gn...@jelmail.com said:
>>> Just experimenting in a sandbox homedir, I noticed that the homedir path
>>> needs to be below a certain size.
>>
>> That is because on most Unix systems the file name for local socket is
>> limited in size.  Local sockets are used for communication between the
>> components (e.g. gpg and gpg-agent).

That is still wrong.  The length of the path of the socket is not
limited in any way, the length of the path passed to connect is.

I still believe we could have/should have made it just work with any
home directory.


Justus


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-15 Thread Daniel Kahn Gillmor 
On Wed 2017-02-15 12:12:23 -0500, Daniel Kahn Gillmor wrote:
> Why does this need to be created manually?  Why not try to create it if
> possible the first time there's a chance to use it, no matter what?
 […]
> What does GnuPG gain from having a known failure mode that requires a
> manual fix?

So one possible issue with my proposal is that by requiring explicit use
of --create-socketdir you remind the user that they're also responsible
for figuring out when to --remove-socketdir.

However, that shouldn't be necessary either.  If gpg-agent or dirmngr
terminates knowing that they should remove their own sockets, they can
do that and then just rmdir(2) on the ephemeral directory path.

If rmdir returns ENOTEMPTY, that's fine -- presumably some other daemon
is also using that path.  if it returns successfully, then the directory
is cleaned up, as it should be.

In --supervised mode, the deamons should not be responsible for removing
any sockets, so they would also not be responsible for cleaning up the
parent directory either.

does this make sense?  Are there any downsides that i'm missing?

   --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-02-15 Thread Daniel Kahn Gillmor 
Hi all--

sorry for the late followup on this thread:

On Mon 2017-01-16 14:16:28 -0500, Werner Koch wrote:
> On Sun, 15 Jan 2017 00:39, gn...@jelmail.com said:
>> Just experimenting in a sandbox homedir, I noticed that the homedir path
>> needs to be below a certain size.
>
> That is because on most Unix systems the file name for local socket is
> limited in size.  Local sockets are used for communication between the
> components (e.g. gpg and gpg-agent).
>
>
> The suggested solution is to create the socket in the /var/run
> directory:  Make sure that 
>
>   /var/run/user/$(id -u)
>
> exists before starting gpg or gpg-agent the socket will be created
> there.  Only is you use a non-default home directory (GNUPGHOME) you
> need to manually create a sub-directory by using
>
>   export GNUPGHOME=/foo/bar
>   gpgconf --create-socketdir

Why does this need to be created manually?  Why not try to create it if
possible the first time there's a chance to use it, no matter what?

or, if "no matter what" is too aggressive, why not at least try to
create the ephemeral it if it's clear that the non-ephemeral location is
longer than the max socket length?

I personally like the simplicity and uniformity of "if /run/user/$(id
-u)/ exists and is writable, then we will use it for the socketdir."

What does GnuPG gain from having a known failure mode that requires a
manual fix?

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG homedir path length limit

2017-01-16 Thread Werner Koch 
On Sun, 15 Jan 2017 00:39, gn...@jelmail.com said:
> Just experimenting in a sandbox homedir, I noticed that the homedir path
> needs to be below a certain size.

That is because on most Unix systems the file name for local socket is
limited in size.  Local sockets are used for communication between the
components (e.g. gpg and gpg-agent).


The suggested solution is to create the socket in the /var/run
directory:  Make sure that 

  /var/run/user/$(id -u)

exists before starting gpg or gpg-agent the socket will be created
there.  Only is you use a non-default home directory (GNUPGHOME) you
need to manually create a sub-directory by using

  export GNUPGHOME=/foo/bar
  gpgconf --create-socketdir

To view the current directory used for the sockets, use:

  gpgconf --list-dirs socketdir


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpV3yKhVAcCI.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GPG homedir path length limit

2017-01-14 Thread John Lane 
Just experimenting in a sandbox homedir, I noticed that the homedir path
needs to be below a certain size.

$ pwd


/home/user/a////eee/fff/ggg

$ mkdir -m 700 alice.gpg

$ gpg --homedir alice.gpg --gen-key

gpg: can't connect to the agent: IPC connect call failed

$ gpg-agent --homedir alice.gpg --daemon

gpg-agent[3857]: socket name
'/home/user/a////eee/fff/ggg/alice.gpg/S.gpg-agent.extra'
is too long


Changing to a shorter path works fine.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users