question on decryption with missing passcode

[Henry Hertz Hobbit]

On 04/18/2013 12:28 AM, Daniel Kahn Gillmor wrote:
> On 04/17/2013 06:25 PM, Daniel Kahn Gillmor wrote:
>> On 04/17/2013 05:05 PM, Beith, Linda wrote:
>>> Gpg: can't open 'rwu.dbdump_Nov2012.sql.gz.gpg' Gpg:
>>> decrypt_message filed: file open error
>> 
>> 
>> This message suggests that there is a problem in the filesystem,
>> 
> 
> on further reflection, this might also indicate that the file does
> not exist in the location (or with the name) that the operator is
> indicating.
> 
> For example:
> 
> 0 dkg at alice:~$ gpg --decrypt does.not.exist.gpg gpg: can't open
> `does.not.exist.gpg' gpg: decrypt_message failed: file open error 2
> dkg at alice:~$

I think this is no longer a decryption issue.  If all you want
is something about encryption, TAP DELETE NOW!  Encryption is
not even discussed here!

In that case, either sha1sum or file (why not do two things at
once?) gives a more meaningful message:

$ sha1sum  nonexistentfile
sha1sum: nonexistentfile: No such file or directory

$ sha1sum foo
sha1sum: foo: Permission denied
$ ls -l foo
-rw-r----- 1 root root 32 2013-04-18 00:08 foo

I just wrote Linda privately since it was no longer an encryption
issue IMO. I hope the leading "rwu." does not mean they are
storing everything in one folder.  No IBM main-frame person would
do that and IBM main-frames have ISAM (Indexed Sequential Access
Method).  Almost a million files in one folder (yes I have saw it
stupidly done not once but twice) is not a pretty sight, and if
you have ext4, something like Reiser isn't going to save you.
You still have O(N/2) on average to do anything with files in
that folder (the dir file, not the inodes the various dir entries
point to).  I would give each client their own folder at minimum
and maybe sub-folders.  Things run much quicker that way all the
way around. What was the clue that they are using a one folder
method?  They are removing the older files.  it could be they
are running out of storage space but we have terrabyte disks now
so it is more likely they are having a one folder for all slow
down.  Disks are cheap.  Make /client an NFS mount and squirrel
away the old drives into storage to be replaced by new disks on
the NFS mount.  You could recycle the old disks after a while.
Make the backups resilient to wait for 30 minutes on fail before
trying again while the old disk is umounted and replaced with the
new disk. And I would much rather have the mount device be a hard
/dev/sd# rather than all the other id stuff too.  Have client folder
pre-made and ready to go before the new disk is mounted.  I have
done some of this stuff in my sleep - literally!  A kot of DB
people do it too.

As I read it, they are somehow able to cd into the folder - perm
711 / 751, (please not 755!), but once they get there the file
has the proper permissions (640) and is hopefully owned by owner
rwu and is in group rwu. I would set each user like rwu with a
umask 027 in their shell start up and then assuming files were
stored in something like (it works for me but maybe not for
SQL DBs):

/client/RogerWilliamsUniversity/
- alternatively
/client/rwu/

me$ su -l rwu
rwu$ cd /client/RogerWilliamsUniversity/${RESTOFPATH}
rwu$ sha1sum -b rwu.dbdump_Nov2012.sql.gz.gpg
rwu$ ls -l rwu.dbdump_Nov2012.sql.gz.gpg
# if succes with sha1sum and ls:
rwu$ gpg -d < rwu.dbdump_Nov2012.sql.gz.gpg | tar -xvf -
rwu$ file rwu.dbdump_Nov2012.sql
rwu$ ls -l rwu.dbdump_Nov2012.sql

Use of the "v" in tar optional.  File not there?

rwu$ find  /client/RogerWilliamsUniversity -type f -name \
rwu.dbdump_Nov2012.sql.gz.gpg -print

There again by having their own folder I reduce the work find
has to do by several orders of magnitude.  I also reduce the
work load in normal operations.  I would prefer 2012_11 which
means you could have YYYY folders and if necessary inside the
year folder a MM folder (month in numerics).  That is just one
method to reduce the directory overloaded with too many files.
But all of the methods have the trait of using subfolders (as
many directories as necessary) according to something that is
naturally there in the data / file names.  Like I said, use
/client/rwu/ if that makes more sense and make the real world
name (GECOS field) for user rwu to be Roger Williams University.

I did ask her to respond on the solution.  It may still be an
encryption issue but I doubt it  Oops, I said something about
encryption.  Excusez mow.

HHH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130418/9f37eaea/attachment.sig>