Hopefully a very simple question.
I have a read-only mount, and a encfs FUSE mount reads over that to decrypt the files. How do I know which encrypted file each decrypted file relates to?
For example: I want to delete a file, however won't be able to do that via the read-only filesystem. How do I know the true filename?
I am possibly looking for a more programmatic way of doing this
I found this is possible encfsctl. You can use encode function to turn the human readable name into the real path on the filesystem.
$ ENCFS6_CONFIG='encfs6.xml' encfsctl encode /encfs/mountpoint readable/name/in/mountpoint
EncFS Password:
decryptedname
http://manpages.ubuntu.com/manpages/hardy/man1/encfsctl.1.html
I found a solution I am not amazingly happy with. I can make up two directories encrypted and decrypted and use the same .encfs6.xml file to mount the decrypted/ directory as the encfs mountpoint.
I can then mkdir -p decrypted/parent/of/file and touch the filename. Then if I check in decrypted I will have the full path of the encrypted file I want.
It's not elegant but it's a solution. Does anyone have any better ideas?
Related
I want to use GPG for local encryption only, and after reading the man file, I'm doing the following in order to encrypt a whole directory:
I zip the directory with a password "zip -r -e foo foo", then I encrypt it with "gpg -c foo.zip" using a passphrase. Is this an elegant and secure way of encrypting directories? Am I using GPG's full cryptographic power? Are there better alternatives?
So there's no a way to encrypt a whole directory without zip it or tar it?
Is this an elegant and secure way of encrypting directories?
Elegant -- no. Secure -- as secure as gpg.
Am I using GPG's full cryptographic power?
Yes.
Are there better alternatives?
tar the directory first instead of zip. gpg compresses data anyway.
lately, I installed encfs for encryption. and I encrypted files.
as far as I know, there are two directories. first directory is encrypted files stored and second directory is unencrypted files stored (It's original files).
I think the purpose of using encfs is reading or writing files safely using encrypted file(in first directory). I'm wrong..??
So my question is how to read encrypted files. the files are encrypted so I can't read or write files without decryption. How to decrypt files??
I think I don't know principle of encfs.. Anyone can explain this problem??
How EncFS works is well explained here: http://ninjatips.com/encrypt-dropbox-using-encfs/
EncFS uses two directories in mounting an EncFS filesystem: the
“rootdir” and the “mountPoint”. Under the “rootdir” directory, every
file is encrypted including its filename and what’s in it. Each file
in the “mountPoint” has a specific file in the “rootdir” directory
that corresponds to it. The file in the “mountPoint” provides the
unencrypted view of the one in the “rootdir” directory
When you mount an EncFS drive, it creates a virtual encrypted filesystem on your computer and stores encrypted data in the rootdir directory and makes the unencrypted data visible at the mountPoint. You add, read, delete... files in the mountPoint. The actual encrypted files are in "rootdir".
While using rsync I would like to filter the files based on read/write attribute and potentially on timestamp. The manual does not mention that this would be possible. Well, is it?
In my shell I can do:
dir *.[CHch](w)
to list all writable source C sources, so I hoped that:
rsync -avzL --filter="+ */" --filter='+ *.[CHch](w)' --filter='- *' remote_host:dev ~/
might work, but apparently it does not.
Any ideas?
As of version 3.0.8, rsync doesn't support filtering on anything other than filename.
Your best bet is probably using find to generate the list of files to sync, and then using rsync's --files-from option. find has most all the options you could ever want for differentiating files.
If I am reading a file stored on an NTFS filesystem, and I try to move/rename that file while it is still being read, I am prevented from doing so. If I try this on a UNIX filesystem such as EXT3, it succeeds, and the process doing the reading is unaffected. I can even rm the file and reading processes are unaffected. How does this work? Could somebody explain to me why this behaviour is supported under UNIX filesystems but not NTFS? I have a vague feeling it has to do with hard links and inodes, but I would appreciate a good explanation.
Unix filesystems use reference counting and a two-layer architecture for finding files.
The filename refers to something called an inode, for information node or index node. The inode stores (a pointer to) the file contents as well as some metadata, such as the file's type (ordinary, directory, device, etc.) and who owns it.
Multiple filenames can refer to the same inode; they are then called hard links. In addition, a file descriptor (fd) refers to an inode. An fd is the type of object a process gets when it opens a file.
A file in a Unix filesystem only disappears when the last reference to it is gone, so when there are no more names (hard links) or fd's referencing it. So, rm does not actually remove a file; it removes a reference to a file.
This filesystem setup may seem confusing and it sometimes poses problems (esp. with NFS), but it has the benefit that locking is not necessary for a lot of applications. Many Unix programs also use the situation to their advantage by opening a temporary file and deleting it immediately after. As soon as they terminate, even if they crash, the temporary file is gone.
On unix, a filename is simply a link to the actual file(inode). Opening a file also creates a (temporary) link to the actual file. When all links to a file have disappeared (rm and close()) then the file is removed.
On NTFS, logically the filename is the file. There's no indirection layer from the filename to the file metainfo, they're the same object. If you open it, it's in use and can't be removed, just as the actual file(inode) on unix can't be removed while it's in use.
Unix: Filename ➜ FileInfo ➜ File Data
NTFS: FileName + FileInfo ➜ File Data
Is there a directory-encryption variant similar to VIM's "vim -x file"? I am looking for something like "mkdir -encrypt folder".
There is no "general" way to encrypt directories (ie, one that works across all file and operating systems) (see below).
You can, however (as Dante mentioned) use TrueCrypt to create an encrypted filesystem in a file, then mount ("attach", in Windows terminology?) that file.
If you're using Linux, you can even mount that file at a particular directory, to make it appear that the directory is encrypted.
If you want to know how to use TrueCrypt, checkout the docs for Windows here: http://www.truecrypt.org/docs/?s=tutorial and for Linux here: http://www.howtoforge.com/truecrypt_data_encryption (scroll down to the "TrueCrypt Download" heading).
So, a quick explanation why you can encrypt files but not directories:
As far as the "computer" (that is, the hardware, operating system, filesystem drivers, etc) is considered, "files" are just "a bunch of bits on disk" (in the same way a book is "just a bunch of ink on paper"). When a program reads from or writes to a file, it can read or write whatever the heck it wants -- so if that program wants to encrypt some data before writing it to the file, or read a file then decrypt the data that it reads, great.
Directories are a different story, though: to read (ie, list) or write (ie, create) directories, the program (be it, mkdir, ls, Windows Explorer or Finder) has to ask the operating systeme, then the operating system asks the filesystem driver "Hey, can you make the directory /foo/bar?" or "hey, can you tell me what's in /bar/baz?" -- all the program or operating system see (basically) is a function to make directories and a function to list the contents of a directory.
So, to encrypt a directory, you can see that it would have to be the filesystem driver that is doing the encryption, not the program creating/listing the directories... And no modern filesystems support per-directory encryption.
On Linux, the simplest way is probably to use EncFS
"EncFS provides an encrypted filesystem in user-space. It runs without any special permissions and uses the FUSE library and Linux kernel module to provide the filesystem interface."
it basically mounts an encrypted folder as a plain one.
More info on wikipedia
TrueCrypt Its open source and supports multiple types of encryption.. What operating system do you wish to know about?
Edit: Windows Vista/XP, Mac OS X, and Linux are all supported.
I would recommend Enterprise Cryptographic Filesystem i.e. ecryptfs found in apt-get as ecryptfs-utils in Debian/Ubuntu because more flexible than TrueCrypt.
It is probably one of the strongest way here to encrypt the directory.
It can be used with two passwords: login passhrase and password so making it a kind of double password system.
It is also POSIX implemented.
The limitation of this system like many other encryption systems is that it supports only filenames/directory names up to 144, in contrast to 255 Linux standard.
Maintained four years and last update 4 months ago so a good thing for future.
Comparison between TrueCrypt and encryptfs from this blog post
Truecrypt is simulated hardware encryption. It creates a virtual
encrypted hard disk, which your operating system can more or less
treat like an ordinary hard disk, but for the kernel hooks Truecrypt
adds to lock and unlock the disk. EcryptFS is an encrypted filesystem.
Unlike Truecrypt, which encrypts individual disk blocks, systems like
EcryptFS encrypt and decrypt whole files.
and more comparasion between the two systems here:
Those complications (and the fact that ecryptfs is slower) are part of
why people like block-level encryption like TrueCrypt, but I do
appreciate the flexibility of ecryptfs.