I am making a password keeper (for my own use), and I want to have a master password in the script. Therefore, it would need to make the script execute-only. It doesn't need to withstand professional hackers or anything, but I don't want someone to be able to just click the file and get the password. I tried chmod 117, but it won't execute. Any ideas?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Python Execute Only?
- Thread starter lynkynpark86
- Start date
- Sort by reaction score
chmod 117 makes no sense. That's owner-read, group-read, everyone read-write-execute. (Wrong. See EDIT below) Owner write & execute are forbidden, as are group write & execute.
If you only want the file's owner to execute something, chmod 700 or chmod 500. 700 is owner read-write-execute, all others forbidden. 500 is owner read-execute (no write), all others forbidden. This assumes you're using the chmod command, not the chmod() C function.
The python code can be compiled, but this won't hide any literal strings.
You could write code that builds the master password string algorithmically. There are any number of ways to do that. A trivial example appends the characters of the password one by one to a string. There are other ways that use character replacement and other transformations.
Or you could use a masking encryption of the plaintext password. For example, ROT13 is trivial "encryption". There are others not quite so trivial, such as a Caesar cipher, or a polyalphabetic cipher. You can look all of those up on wikipedia.
Then you have to protect your masking password or key, too, so masking is hardly the solution it first seems to be.
EDIT
Oops, 117 is owner-execute, group-execute, everyone read-write-execute. It still makes no sense, because everyone other than owner or group can both read and write to the file. That's the exact opposite of being secured.
If you only want the file's owner to execute something, chmod 700 or chmod 500. 700 is owner read-write-execute, all others forbidden. 500 is owner read-execute (no write), all others forbidden. This assumes you're using the chmod command, not the chmod() C function.
The python code can be compiled, but this won't hide any literal strings.
You could write code that builds the master password string algorithmically. There are any number of ways to do that. A trivial example appends the characters of the password one by one to a string. There are other ways that use character replacement and other transformations.
Or you could use a masking encryption of the plaintext password. For example, ROT13 is trivial "encryption". There are others not quite so trivial, such as a Caesar cipher, or a polyalphabetic cipher. You can look all of those up on wikipedia.
Then you have to protect your masking password or key, too, so masking is hardly the solution it first seems to be.
EDIT
Oops, 117 is owner-execute, group-execute, everyone read-write-execute. It still makes no sense, because everyone other than owner or group can both read and write to the file. That's the exact opposite of being secured.
Last edited:
OK, but is there a way to allow execute but not read, and still have a successful execution?
It depends.
Native code can be marked execute-only (i.e. no read, no write), but I'm doubt it works on interpreted code. Since python byte-codes are interpreted, even after being compiled, I suspect that a true execute-only permission would prevent reading by the interpreter. Execute-only for owner is chmod 100. Try it. See what happens.
I don't see why mode 500 is insufficient. It allows read and execute only to the owner. If the owner is your user account, then only you can read or execute it. Why is that not a sufficient solution to the problem of preventing others from reading?
Since you own the file, you can also change the permissions at any time. No security is gained by forbidding read, since you can choose to allow it at any time. By "you" I actually mean "any program running under your user id", which can call chmod to allow reading, do the reading, then chmod back. Boom, you're compromised.
There are more complex access rules definable using ACLs (Access Control Lists), but without a more detailed explanation of what you're trying to accomplish, and why mode 500 fails to accomplish it, I don't see why you'd bother with that complexity.
If you expect other people to be using your user account, then no amount of permission bits or ACLs can prevent access. The computer can't magically see who's typing and forbid your sister while giving you access. That leaves masking or similar encryption schemes.
Last edited:
Like I said, it's like making a file hidden: I just want to avoid casual opening of the file. I do not need to actually prevent opening it, but i'd like to somewhat avoid it. But someone seeing "passwordkeeper.py" on the desktop might be a little intriguing...
EDIT: Is my IQ 9 or something? I've been comparing this to hiding the file the entire time, but hiding it will do quite nicely. Thanks for the help, and I did add the replace string like you said, which could also help prevent deciphering by those without "teh codez" (from StackOverflow).
Last edited:
You haven't identified who you're protecting the file from. So to the statement "I just want to avoid casual opening of the file", I ask, "By whom?".
Similarly, this "someone" who sees a file on the desktop, what do you mean by "someone" and "sees"? Do you mean a person physically observing your screen?
Do you mean another user account logged in? If so, then you should already be protected from that, because an account's Desktop folder isn't public-read by default. Try accessing your file from another user account to confirm. Or enter this command in Terminal:
Code:
ls -l ~The basic answer here is that you can't do this in Python, and stashing a hard-coded password that can't easily be found by someone with a little knowledge is a difficult thing in all languages.
Now what you should be doing is telling us what your actual goal is, not what you think is the answer. You will always get far better answers that way.
That all being said, the only way of doing anything like what you seem to want to be doing is to use the Keychain, and that is only going to work against applications that can be code-signed, so that the keychain can be told to release the password to them. There is a way of doing this for command-line binaries, but I am a little foggy on those details. But this will never work for a Python (or any other interpreted) script, baring using one of the python-c-compilers (another layer of complexity there).
Now what you should be doing is telling us what your actual goal is, not what you think is the answer. You will always get far better answers that way.
That all being said, the only way of doing anything like what you seem to want to be doing is to use the Keychain, and that is only going to work against applications that can be code-signed, so that the keychain can be told to release the password to them. There is a way of doing this for command-line binaries, but I am a little foggy on those details. But this will never work for a Python (or any other interpreted) script, baring using one of the python-c-compilers (another layer of complexity there).
How would this be any better than just making an encrypted dmg file with DiskUtility and storing plain text in it?