You are not logged in. Please login or register.
ha ha wut
i was just being a pissydick over your use of the GPL
ha ha wut
i was just being a pissydick over your use of the GPL
Why do you hate my freedom?
it's too long, didn't read
Just if you want to work more on it:
You are storing unencrypted passwords on the filesystem. Perhaps someone could look at them if they did "forensics" or some shit.
I suppose storing it on an environment variable isn't much better, either.
Same as storing it on a tmpfs.
I guess a shell variable that is not 'export'ed is not an environment variable, but just private to the shell. that might be usable.
What if I store it in /dev/shm ?
Afaik that should work except for if they rapid cool the memory, but that's also a problem with veracrypt / truecrypt etc anyways, and if you're in a situation where someone is doing that you're probably fucked already.
Ideally, you should not store it in any file that actually gets written to a permanent media somehow. I'd say store it at some malloc()-ed place and fill it with random data after you're done but I guess that's not an option for you in bash.
Maybe create a temporary ramdisk, store temp_pass.txt there, fill it with junk before unmounting the ramdisk?
However, even that is somewhat of a problem, since -- as long as it's mounted -- the ramdisk is still readable by other processes with the same UID as the user executing the script (not to mention the complication of mounting it).
Yes. tmpfs (/tmp) these days is also just /dev/shm backed by a disk store. tmpfs has a much lower interval for syncing dirty buffers than regular physical store-backed file systems, but as it's ephemeral and gets flushed on reboot, you could use it to get the benefits of having a full VFS I/O interface.
Assuming your distro has a tmpfs on /tmp. If not, mount one yourself.
I'm not sure how reading and writing to/from ssh is treated in the context of shell. I.e. if I keep reading from /dev/shm in a tight loop, from process A, is there any chance that I might stumble upon what's written there from process B?
In this particular case, if I keep doing cat /dev/shm, are the contents of that temporary .txt file going to be output at some point?
(Note: honest question. I've never used shm for anything other than actual IPC so...)
I'm not entirely sure. My slack install's /tmp has not been cleaned out in ages so it doesn't seem like it's using ram. I vaguely recall fucking up tmp somehow ages ago and never fixing it, because I ended up just manually creating a /tmp directory like a retard.
Are there OS's that /tmp is not in ram? If so I think I ought to err on the side of caution and try to use something like /dev/shm. So it looks like I"ll be doing some research into how it works.
In any case, under almost all situations modern operating systems afaik will create separate RAM areas for you and you can't really do the whole memory leaking thing anymore. That's what I was told in one of my programming classes though. Back in the day you could just dump memory to read various info from programs, but that has largely been fixed. Still, I should try to include any kind of separation I can myself.
Although let's be clear, the temp file will only last until the user quits the program, where the script deletes it. Still, I"ll look into it.
The problem with tmpfs is that if RAM is full, it'll spill over into swap on the disk. ramfs however looks a little resource intensive based on the debian wiki: https://wiki.debian.org/ramfs
That's probably negligible for a single mount, create, read, delete, unmounted? I don't really know, but it seems expensive for a simple operation. I will definitely look for a way to determine if /tmp is a tmpfs through shell. But idk, I don't want it spilling into swap. Ugh.
What I said earlier seems wrong. I think /dev/shm is intentionally world readable and as such you could probably find the .txt file if you were quick enough from another user... I think the best, most portable method here is just going to be creating a ramfs quickly, using it, then unmounting it. I really have no idea how resource intensive this is, though.
Edit: Ok I have an idea.
lmfao look at this shit now. The sed might be kind of messy and the workaround if the user doesn't have /tmp as a tmpfs or /dev/shm as a tmpfs is a little sketchy, but it works to keep the passwords off of the disk 100% of the time. I ended up using tmpfs because I thought it could be used by non-root users, but apparently not. So sudo is required twice if you don't already have a tmpfs on your system. That's kind of to be expected though, right?
It might be sensible to just use the custom tmpfs the whole time, but that always requires root. I guess in tmpfs any user is able to dump the /dev/shm or /tmp directory looking for the file? Like, if i su to another user obviously they can just peak in /dev/shm and the file is sitting there... At least while the user is running the script until it deletes it. So for a multiuser system it makes way more sense to use root for the users own tmpfs. BUT, then if it's a multi-user system, why do you even have access to root unless you're the sysadmin??? That use case doesn't make much sense in this context.
tmpfs will dump into the disk through swap if ram is full, so to mitigate this I made sure there was plenty of space in ram before allowing the file to be created in any tmpfs directory. All in all this script is cool as shit imo. For a single user system anyway.
I may have just wasted a few hours by not reading loons reply closely enough and using a shell variable.
The code is sexy but like half of it may be totally unnecessary...
The Bourne shell family does not really distinguish between shell and environment variables. When a shell starts up, it reads the information in the table of environment variables, defines itself a shell variable for each one, using the same name (also uppercase by convention), and copies the values. From that point on, the shell only refers to its shell variables. If a change is made to a shell variable, it must be explicitly "exported" to the corresponding environment variable in order for any forked subprocesses to see the change. Recall that shell variables are local to the shell in which they were defined.
Ok, but where are local shell variables stored...
No, this makes it very clear that I fucked up and wasted a lot of time:
Oh well, it was cool learning all that shit and writing all that code I guess.
That's how learning happens, man, don't be sorry.
What in the fuck: http://git.zx2c4.com/password-store/tre … openbsd.sh
Why are they even doing this lmfao.
You can just pass a flag and it does code completion.
It looks like "pass" is implemented how I just had it before changing back to shell variables. kek
This is definitely coming along. I was considering using shred: http://linux.die.net/man/1/shred
But it doesn't work on some file-systems. I ended up figuring out how to use gpg with a stream from a variable, so that's unnecessary. Nothing touches the file-system as far as I know until it's encrypted directly from GPG. You can add new sections now.
To be implemented:
I'm pretty glad I haven't had to use my implementation of tmpfs anywhere, and it keeps it very simple. Eventually this can be made POSIX compatible and thus relatively cross-platform for anyone with a bash-like shell.
Finally finished setting up all of this camera junk:
Now I just have to install one more and add it to the script and we're solid. Already have the router all set up for it. Should be pretty quick, just need a cordless saw.