[PATCH] gensignkey: ensure host keys are flushed to disk
DELOGET, Emmanuel
emmanuel.deloget at sfr.com
Tue Dec 2 00:25:13 AWST 2014
Le lundi 01 décembre 2014 à 12:48 +0100, Peter Korsgaard <> a écrit :
> >>>>> "DELOGET," == DELOGET, Emmanuel <emmanuel.deloget at sfr.com> writes:
>
> Hi,
>
> >> Thanks for the patch, I've applied it with small changes.
> >> https://secure.ucc.asn.au/hg/dropbear/rev/fd2e8bbb0333
> >>
> >> Emmanuel - thanks for the review. Dropbear already has
> >> exit-on-failure m_strdup(), I'm using that. I'll avoid
> >> O_DIRECTORY since it's fairly harmless to leave out and is a
> >> portability hassle. I've made it open with O_RDWR though can't
> >> actually see in the opengroup.org posix docs where that is
> >> required for fsync?
>
> > Part of the problem has its root here: the POSIX standard does not say a
> > word on this specific issue - so different UNIX have different
> > implementation. I found at least two of them:
>
> > http://nixdoc.net/man-pages/irix/man2/fsync.2.html
> > http://nixdoc.net/man-pages/Tru64/man2/fsync.2.html
>
> > Granted, there are not the primary target for dropbear :)
>
> > The linux man page warns about that issue in the Notes section:
>
> > http://linux.die.net/man/2/fsync
>
> > Additionnally, a good number of other UNIX (and other POSIX layers such
> > as the one offered by eCos) doesn't say anything about that so it's hard
> > to know how the implementation behaves without testing it.
>
> > I might be a bit over-prudent here and maybe noone will ever notice. But
> > since it can lead to a nasty bug I think it's better to err on the side
> > of safety :)
>
> Actually it is the other way around. Something related came up today,
> and I finally now got to test what got committed. It doesn't work (on
> Linux atleast) as open on the parent directory fails with -EISDIR unless
> it is opened read only. This is also documented in the man page:
>
> EISDIR pathname refers to a directory and the access requested involved
> writing (that is, O_WRONLY or O_RDWR is set).
>
> The exact code handling it in the kernel is in fs/namei.c:
>
> static int may_open(struct path *path, int acc_mode, int flag)
> {
> struct dentry *dentry = path->dentry;
> struct inode *inode = dentry->d_inode;
> int error;
>
> /* O_PATH? */
> if (!acc_mode)
> return 0;
>
> if (!inode)
> return -ENOENT;
>
> switch (inode->i_mode & S_IFMT) {
> case S_IFLNK:
> return -ELOOP;
> case S_IFDIR:
> if (acc_mode & MAY_WRITE)
> return -EISDIR;
> break;
> ...
>
> So we either need to change it back to O_RDONLY, or first try with
> O_RDWR and fall back to O_RDONLY if it fails with EISDIR in case other
> OSes require RDWR access for fsync.
The first thing that came to my mind is: "damned". That's sooo stretched
from a POSIX point of view! :)
> What are we going to do?
Either (option 1) go the road of a simple patch (keep O_RDONLY) and wait
for users to complain (this might never happen) or (option 2)
encapsulate fsync-on-a-directory into something that will work on any
systems (maybe with some configure magic here and there).
Further reading on the Intarweb lead me to:
* Tru64 has been EOL'ed by HP [1]. Yet, dec-osf (another name for Tru64)
is still a dropbear target [2] so it might be interesting to keep it.
* Last (minor) version of IRIX dates from 2005, and the OS has been
EOL'ed in 2006 [3].
So the only two occurences I found target OSes that are no longer
developped nor maintained. They might still be in use although I'm not
sure this use goes beyond hobbyism (I would not like to support a
discontinued platform as a professionnal). Option 1 above might be
enough for now.
[1]http://fr.wikipedia.org/wiki/Tru64_UNIX
[2]https://secure.ucc.asn.au/hg/dropbear/file/fd2e8bbb0333/configure.ac#l68
[3]http://en.wikipedia.org/wiki/IRIX
In any case, I have to apologize for all that fuzz - it seems I've been
plain wrong on that case. I should have known better: test before you
assert something. This way, I would have seen that opening a directory
as writable was not possible.
Sorry for that,
-- Emmanuel Deloget
More information about the Dropbear
mailing list