[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bacula-devel
Subject:    Re: [Bacula-devel] data encryption problem in FreeBSD
From:       Dan Langille <dan () langille ! org>
Date:       2015-07-29 12:58:51
Message-ID: 03280304-EB80-48C8-9B3C-E071A44BCD0C () langille ! org
[Download RAW message or body]


> On May 22, 2015, at 12:55 AM, Devin Reade <gdr@gno.org> wrote:
> 
> I've been looking more into the failure mentioned in
> <http://osdir.com/ml/bacula/2015-05/msg00171.html> whereby trying to
> enable data encryption in the FD fails, *unless* the fd is running in
> the foreground (via the -f flag).
> 
> (Bacula 7.0.5 running on FreeBSD 9.3, which is the version on which
> the current stable FreeNAS is based.)
> 
> I've tracked things down in Bacula code to the call to EVP_CipherInit_ex
> at around line 1307 in src/lib/crypto.c in crypto_cipher_new().  That call
> fails, however we don't get any diagnostics; openssl_post_errors() in
> openssl.c doesn't record anything because ERR_get_error() never returns
> non-zero.
> 
> I attached to both the backgrounded and non-backgrounded processes
> via truss to look for differences.  Here in the foreground (working)
> process we see:
> 
>  open("/mnt/pool1/local/etc/bacula/testfile",O_RDONLY,00) = 10 (0xa)
>  ioctl(3,CRIOGET,0xff7fb25c)                      = 0 (0x0)
> 
> Bacula opens the file to be backed up, and the ioctl appears to be the
> first system call made in EVP_CipherInit_ex (file descriptor 3 is,
> I believe, /dev/crypto).  The CRIOGET ioctl looks like it dups the
> original file descriptor. (Why, I don't know.) The 3rd arg is the
> address of the int that is the target of the dup.
> 
> Now the failing case:
> 
>  open("/mnt/pool1/local/etc/bacula/testfile",O_RDONLY,00) = 10 (0xa)
>  ioctl(3,CRIOGET,0xff5fa25c)         ERR#25 'Inappropriate ioctl for 
> device'
> 
> WTF? So it makes it look like in at least FreeBSD 9.3 /dev/crypto file
> descriptors can't be cloned unless it is a foreground process.  You would
> think that this is something that was noticed a long time ago.
> 
> I'm wondering, with all the OpenSSL updates recently, if this is a case
> where a newer OpenSSL was backported and this regression was missed.
> 
> Does my assessment sound feasible?  Does anyone have Bacula 7.0.5
> installed on a more recent FreeBSD and is able to validate if data
> encryption works?  (This doesn't seem to impact network encryption.)

Any more recent news?

I have FreeBSD 10.1 and 10.2-BETA2.

— 
Dan Langille
http://langille.org/






------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

[prev in list] [next in list] [prev in thread] [next in thread]