Can someone explain to me what all the passwords are for. I’ve read the developer docs several time trying to find info on this, but they don’t explain in depth.
When you do something like:
do shell script “sudo someCommand” password "somePassword with administrator privileges
I’m thinking that the password is for the shell, but what is administrator privileges for. If I leave that out it says something like “the script doesn’t have a pass phrase”. What is that? I’ll try to run it again and get the exact message. But if you know what I’m writing can you explain?
Ah, that’s what I’ve been doing wrong. So, once you enter the admin password, it will last until you login again. But, you always need the password right? So that you don’t get another password dialog from the shell.
That’s what I thought about the 5 minutes. But, when I ran the script again just a little while ago there wasn’t any password dialog and I last entered it last night. I’ll check it out.
I wonder if it’s supposed to be 5 minutes after the application quits. Because I ran this and didn’t need to enter password in a dialog:
set cur_date to current date
set target_date to (cur_date + 1 * minutes) as «class isot» as string
do shell script "date -jf '%Y-%m-%dT%H:%M:%S' '" & target_date & "' '+%m/%d/%y %H:%M:%S'"
set format_date to result
do shell script "pmset displaysleepnow; pmset schedule wake \"" & format_date & "\"" password "myPass" with administrator privileges
I ran it from Script Editor and it awoke in about a minute.
Although, the not needing sudo works! Now I know how it works for the most part.
At 45 seconds the screen came back on with the dummy password. I am not understanding this:
set cur_date to current date
set target_date to (cur_date + 1 * minutes) as «class isot» as string
do shell script "date -jf '%Y-%m-%dT%H:%M:%S' '" & target_date & "' '+%m/%d/%y %H:%M:%S'"
set format_date to result
do shell script "pmset displaysleepnow; pmset schedule wake \"" & format_date & "\"" password "myPass" with administrator privileges
The most common misconception about do shell script command is that it is in not the same as a terminal. Without being to vague the difference is that the Terminal opens a interactive shell, the do shell script command uses a non-interactive shell. But a script that is run by the Terminal, inside that script, there is an non-interactive shell. So the do shell script’s shell code will run as it was inside a normal running script file. So the first mistake is made when you think you can use sudo the same way as you do in the Terminal.
Knowing that a do shell script runs in the same context as a normal script file does, we have to follow the guidelines for shell scripting. Inside a shell script you shouldn’t use sudo either. You run the script as root or not, as a scripter you’re not individually telling each command to run as root or not. For that same reason Apple says it’s bad practice to use sudo inside do shell scripts. When a shell script needs to run as root you often see this kind of code:
#!/bin/bash
if [ $UID != 0 ]
then
echo 'Script needs to be run as root.' >&2
exit 2
fi
Of course, you won’t need that in AppleScript because the user prompt for password is enough. But this code shows that just like sudo, your code will actually run as root.
I’ll have to reread your post when I get up, but what you’re saying I think is that once you enter the admin password, the script has root privileges. Also, As Stefan has wrote is that it last for 5 minutes. Think I see that the tty thing is because the do shell script is non-interactive. That’s why I got the error message. I’ve never seen that part about the documents saying to never use sudo (or don’t remember), but I’ll read this again probably many times. That’s what I wanted to know I think.
Thanks a lot,
kel
ps.I just hit my head oweeee on something. Can’t think too good for the moment. Starting to get a lump there. Will read it again tomorrow.
I was giving some background information why you shouldn’t try to solve it. You could pipe the password to sudo with the option -S to solve your problem but that is bad practice and hope it explains why.
Correct, by default. With visudo you can change the timeout.
Correct. Sudo will try to get the password stored in the terminal (read:stored in tty, not Terminal.app). This hasn’t been the default in earlier Mac OS X system but it requires less password typing.
There is or at least was a “sudoers” file, that can govern who, and for how long the sudo command should last. If memory serves me right. man sudo has the correct information, if it is the correct man file.
There still is but when you edit with visudo the system will be informed about the changes to the file. Also visudo is safe because it will do a syntax check and locks the file when it writes to it. When used by another text editor all of this won’t happen.
I’ve been looking into sudoer and visudo man pages. New and interesting stuff.
Anyway, I’ve been running this as application to test and haven’t needed to enter password after initial run:
property pw : missing value
property first_run : true
if first_run then
display dialog "Enter password:" default answer ""
set pw to text returned of result
set first_run to false
end if
set cur_date to current date
set target_date to (cur_date + 1 * minutes) as «class isot» as string
do shell script "date -jf '%Y-%m-%dT%H:%M:%S' '" & target_date & "' '+%m/%d/%y %H:%M:%S'"
set format_date to result
do shell script "pmset schedule wake \"" & format_date & "\"" password pw with administrator privileges
do shell script "pmset displaysleepnow"
I’ll be test running it to find when the passphrase again will be needed.
Note to others: hiding the password like this is not secure. It’s ok for me.
Edited: also, It still worked without password after cold startup.
When a variable needs to be set for the first time you could also use:
property pw : missing value
if not exists pw then --or if pw = missing value then
set pw to text returned of (display dialog "Enter password:" default answer "")
end
This eliminates the extra variable. Exists command will return false for missing value, and true for every other value.
Just for the record: That is because properties, like the alias class, are persistent as long as you don’t recompile the script. Globals are persistent as well but only between initializations.
That is much better! I remember seeing that. It’s an old habit that I used to write it like that.
About storing the password as property, I know about the persistence. What I meant was that, I’m wondering when the system will ask for the password again, if ever (i.e. there is no 5 minute limit as I thought there would be). That’s good.
Will read it again tomorrow.