I write script in TCL and want to get my email address.
Is there any way to get my email address?
Unless you're lucky and it's in an environment variable, there's no way to get that unless you've provided for it in an explicit setting. In terms of standard ones, the USER or LOGNAME environment variables might be set (the latter is more email-address-like) but neither have the hostname for making a full mailbox address, as that's often different from the local machine name (and DNS might not have a helpful record). Plus a lot of people have email addresses that are just totally different from their local username and machine name. How is anyone to guess that someone is joe.schmoe.1234567890 at gmail without being told explicitly when their local username is just js or js2000?
Ask explicitly, either interactively (this gets annoying if used a lot) or through setting something. Could be in a configuration file, via a command line argument, or an environment variable.
# Interactive on the terminal
puts -nonewline "Email address: "
flush stdout
gets stdin email
# From a command line argument; use the argv global list
set email [lindex $argv 1]
# Probably need more complex parsing than that
# From an environment variable
set email $env(USER_EMAIL_ADDRESS)
# From a simple setting file, in this case holding a Tcl dictionary
set f [open "my.setting.file.txt"]
set data [read $f]
close $f
set email [dict get $data "email"]
I want to create env parameter
that the key is a:b or a#b
I need to do it from bash script or from terminal , it should work from linux or windows
when I tried it export a:b=c
I got an error
not a valid identifier
When I tried
export tempKey = a:b then It worked but then I didn't know how to use the value a:b to create it as key
Could you please advise ?
None of the commonly used unix shells will let you create a var whose name includes characters not legal in an identifier (typically letters, digits and underscore). The simplest workaround is to use the env command since it doesn't impose any restrictions on the strings it puts in the environment. For example, env a:b=c a_cmd where a_cmd is whatever command needs that environment string. If you want it to be part of the shell's environment do exec env a:b=c $SHELL. Obviously the new shell won't be able to use that var since $a:b is not a valid var reference even if you enclose the var name in braces.
I'd like to prepare a simple script for connecting to some VPN network. The password to the network consists of two elements: pretty complicated pass + randomized token. I don't want to remember this password but store it encrypted in some secure directory. Now, the script I need should ask me for a passphrase and some token, read decrypt a pass from a file and run some commands. All those are pretty easy except one thing: is it possible to decrypt a file to a variable instead of file? I mean I'd like to get something like
PASS=`mdecrypt password.nc`
but as far as I know mdecrypt generates a file as a result instead of returning value. I know I could run something like
`mdecrypt password.nc`
PASS=`cat password`
`unlink password`
but is there some easier (one liner) solution?
uset the -F option
-F Force output on standard output or input from stdin if that is a
terminal. By default mcrypt will not output encrypted data to
terminal
I have a shell script that I use to do a few things requiring an actual IP address and the DNS name (for readability to the user).
A user will create a shell properties file containing variables that will be used in the script, and one of those variables contains a path and a DNS name for a server. It's setup like this:
PROJ="Blah"
SERVER_NAME="MyServer"
SERVER_PATH="/<path>/$SERVERNAME/aFile/"
In my script, I require the IP address of $SERVER_NAME. So I have a function that extracts the IP address, but I need to substitute that information into the $SERVER_PATH variable and then use the $SERVER_PATH variable. Is there anyway I can do this?
My answer was right in front of me the entire time. I just needed to replace $SERVER_NAME with the IP I obtained from my function.
I essentially just did SERVER_NAME=$SERVER_IP and that was it. I made it much more complicated than it needed to be!
Is it safe to pass a key to the openssl command via the command line parameters in Linux? I know it nulls out the actual parameter, so it can't be viewed via /proc, but, even with that, is there some way to exploit that?
I have a python app that I want to use OpenSSL to do the encryption/description through stdin/stdout streaming in a subprocess, but I want to know my keys are safe.
Passing the credentials on the command line is not safe. It will result in your password being visible in the system's process listing - even if openssl erases it from the process listing as soon as it can, it'll be there for an instant.
openssl gives you a few ways to pass credentials in - the man page has a section called "PASS PHRASE ARGUMENTS", which documents all the ways you can pass credentials into openssl. I'll explain the relevant ones:
env:var
Lets you pass the credentials in an environment variable. This is better than using the process listing, because on Linux your process's environment isn't readable by other users by default - but this isn't necessarily true on other platforms.
The downside is that other processes running as the same user, or as root, will be able to easily view the password via /proc.
It's pretty easy to use with python's subprocess:
new_env=copy.deepcopy(os.environ)
new_env["MY_PASSWORD_VAR"] = "my key data"
p = subprocess.Popen(["openssl",..., "-passin", "env:MY_PASSWORD_VAR"], env=new_env)
fd:number
This lets you tell openssl to read the credentials from a file descriptor, which it will assume is already open for reading. By using this you can write the key data directly from your process to openssl, with something like this:
r, w = os.pipe()
p = subprocess.Popen(["openssl", ..., "-passin", "fd:%i" % r], preexec_fn=lambda:os.close(w))
os.write(w, "my key data\n")
os.close(w)
This will keep your password secure from other users on the same system, assuming that they are logged in with a different account.
With the code above, you may run into issues with the os.write call blocking. This can happen if openssl waits for something else to happen before reading the key in. This can be addressed with asynchronous i/o (e.g. a select loop) or an extra thread to do the write()&close().
One drawback of this is that it doesn't work if you pass closeFds=true to subprocess.Popen. Subprocess has no way to say "don't close one specific fd", so if you need to use closeFds=true, then I'd suggest using the file: syntax (below) with a named pipe.
file:pathname
Don't use this with an actual file to store passwords! That should be avoided for many reasons, e.g. your program may be killed before it can erase the file, and with most journalling file systems it's almost impossible to truly erase the data from a disk.
However, if used with a named pipe with restrictive permissions, this can be as good as using the fd option above. The code to do this will be similar to the previous snippet, except that you'll need to create a fifo instead of using os.pipe():
pathToFifo = my_function_that_securely_makes_a_fifo()
p = subprocess.Popen(["openssl", ..., "-passin", "file:%s" % pathToFifo])
fifo = open(pathToFifo, 'w')
print >> fifo, "my key data"
fifo.close()
The print here can have the same blocking i/o problems as the os.write call above, the resolutions are also the same.
No, it is not safe. No matter what openssl does with its command line after it has started running, there is still a window of time during which the information is visible in the process' command line: after the process has been launched and before it has had a chance to null it out.
Plus, there are many ways for an accident to happen: for example, the command line gets logged by sudo before it is executed, or it ends up in a shell history file.
Openssl supports plenty of methods of passing sensitive information so that you don't have to put it in the clear on the command line. From the manpage:
pass:password
the actual password is password. Since the password is visible to utilities (like 'ps' under Unix) this form should only be used where security is not important.
env:var
obtain the password from the environment variable var. Since the environment of other processes is visible on certain platforms (e.g. ps under certain Unix OSes) this option should be used with caution.
file:pathname
the first line of pathname is the password. If the same pathname argument is supplied to -passin and -passout arguments then the first line will be used for the input password and the next line for the output password. pathname need not refer to a regular file: it could for example refer to a device or named pipe.
fd:number
read the password from the file descriptor number. This can be used to send the data via a pipe for example.
stdin
read the password from standard input.
All but the first two options are good.