Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > How do I run a shell script on login?

How do I run a shell script on login?
Thread Tools
itistoday
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 20, 2005, 09:27 PM
 
Hello, I need to run a shell script everytime I login to my computer, and I'd like it to run in the background. The script is a one liner that runs a command line program in the background. How do I do this?

Thanks for any suggestions.

Edit: I found one way: add the extension .command to the script and give it execution priveleges. However, this means that Terminal.app will open up on login. Is there a better way?
( Last edited by itistoday; Mar 20, 2005 at 09:47 PM. )
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Mar 20, 2005, 10:06 PM
 
Originally posted by itistoday:
Hello, I need to run a shell script everytime I login to my computer, and I'd like it to run in the background. The script is a one liner that runs a command line program in the background. How do I do this?

Thanks for any suggestions.

Edit: I found one way: add the extension .command to the script and give it execution priveleges. However, this means that Terminal.app will open up on login. Is there a better way?
you could wrap it in Platypus as an Application (there's also another application out now that wraps scripts into Mac OS X apps, but I can't remember it's name). Or similarly, write an AppleScript that calls it (or write an apple script that runs the unix command without any intermediate shell script).
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Mar 21, 2005, 12:17 AM
 
The way OSX does it with Apache, which is the best example I can find on the System, is firstly, to make a directory in /System/Library/StartUpItems/ and then place a script with the predefined functions in rc.common in there. So, possibly, you could simply place a script in that directory that directly executes instead of needing to be called.
weird wabbit
     
Brass
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Mar 21, 2005, 12:21 AM
 
Originally posted by theolein:
The way OSX does it with Apache, which is the best example I can find on the System, is firstly, to make a directory in /System/Library/StartUpItems/ and then place a script with the predefined functions in rc.common in there. So, possibly, you could simply place a script in that directory that directly executes instead of needing to be called.
You should NEVER modify anything within the "System" directory hierarchy without a very good reason.

If you need to put anything in the Library directory, do it in the root "Library" directory, ( /Library ) not the System library ( /System/Library ). NB: you may need to create a "StartUpItems" directory in /Library if it does not already exist.

Having said that, this will create a startup item, NOT a login item, which is quite different.
     
Krusty
Professional Poster
Join Date: Oct 1999
Location: Always within bluetooth range
Status: Offline
Reply With Quote
Mar 21, 2005, 12:23 AM
 
Besides the good ideas presented above, Applescript can wrap shell scripts nicely (just write "do shell script" <insert command> in an AppleScript), save it as an Application that closes after running, put in your login items and set it to Hide.
( Last edited by Krusty; Mar 21, 2005 at 12:37 AM. )
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 21, 2005, 12:32 AM
 
Yes, actually I did some googling and am in the process right now of making a startup item in /Library/StartupItems. I'm having some really odd difficulties... don't know why. I actually got it to work by placing the line to run the script in another third-party startup item already installed, and it works there, but I'm having difficulties getting my own startup item to work. I think it might have to do with permissions or something. Will report back when I get it to work in its own StartupItem.
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Mar 21, 2005, 12:38 AM
 
Originally posted by Brass:
You should NEVER modify anything within the "System" directory hierarchy without a very good reason.

If you need to put anything in the Library directory, do it in the root "Library" directory, ( /Library ) not the System library ( /System/Library ). NB: you may need to create a "StartUpItems" directory in /Library if it does not already exist.

Having said that, this will create a startup item, NOT a login item, which is quite different.
True, there's a StartUpItems in /Library as well, and messing with /System can be risky. As for log-in items, the only real way is to add it the accounts StartUpItems list, but that doesn't let you run shell scripts directly, AFAIK, which would mean you need to put it in an AppleScript. As I understand it, the original poster wants the script to run in the background, which is normally done with the "&" sign in a shell script. Perhaps adding it to /etc/bashrc ?
weird wabbit
     
Detrius
Professional Poster
Join Date: Apr 2001
Location: Asheville, NC
Status: Offline
Reply With Quote
Mar 21, 2005, 01:11 AM
 
There's a login hook feature that allows you to run shell scripts on login and logout. However, I've never done this, so I couldn't get you directions. I believe the info is all at http://www.afp548.com
ACSA 10.4/10.3, ACTC 10.3, ACHDS 10.3
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 21, 2005, 01:40 AM
 
Ok, I give up. I've tried virtually everything to get it working via StartupItems�doesn't work. I tried Detrius's loginhook suggestion�didn't work. The only thing that works so far is my .command trick.

Here's exactly what I'm trying to do:

I have a script that uses ssh to create a secure tunnel from my computer to my email provider's SMTP port. My email provider doesn't have secure SMTP so I have to resort to this. So the script uses the & to put this tunnel in the background. This allows me to set my SMTP server in Mail.app's preferences to localhost on port 10025. It is then forwarded through ssh to my email provider's server.

When I tried making a startup item that called the script, the startup item would load, but when I logged in, no ssh process existed. In the startup item script I even tried doing: "sudo -u myusername /Path/to/script.sh" to run it as my user, but that didn't work either (although it does work when I'm already logged in and do it in the Terminal).

Oh well... too tired to work on this anymore tonight.
( Last edited by itistoday; Mar 21, 2005 at 01:47 AM. )
     
bmedina
Mac Elite
Join Date: Jan 2000
Location: Seattle, WA, King
Status: Offline
Reply With Quote
Mar 21, 2005, 02:19 AM
 
Everything you need to know here: http://www.bombich.com/mactips/loginhooks.html
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 21, 2005, 02:51 AM
 
Originally posted by bmedina:
Everything you need to know here: http://www.bombich.com/mactips/loginhooks.html
Thanks for the link! Following Detrius's suggestion I tried something like this before, but this was slightly different. I followed the directions on the site exactly, and it didn't work...BUT�the website seemed so sure of itself, and so well designed that I decided to press on thinking, "This has got to be some error on my part." And, it was

What finally got it working was modifying the script itself to specifically include the paths of each command *doh!* i.e: /usr/bin/sudo -u username /usr/bin/ssh .... etc

I bet the reason the StartupItem wasn't working is for the same reason too... but I don't want to deal with that anymore, I like this way of doing it just fine
     
VValdo
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
Mar 22, 2005, 02:55 PM
 
BTW-- if you ever lose your SSH connection and need to re-establish it (say you put your computer to sleep or something), a quick way to do it is to put the script in

~/Library/Scripts/

then install Script Menu:

http://www.apple.com/applescript/scriptmenu/

And you'll have a nice pulldown that will execute the script whenever you want. This works for shell scripts, applescripts, etc.

W
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 22, 2005, 03:21 PM
 
Thanks! Awesome hint!
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 22, 2005, 03:31 PM
 
Originally posted by bmedina:
Everything you need to know here: http://www.bombich.com/mactips/loginhooks.html
I actually don't like this.

A hidden preference that lets any shell script get run invisibly when you log in? That's a great place for any piece of malware to hide the code to launch an invisible daemon on login, and most users would never know about it since the preference is hidden.

This should be in System Preferences, not hidden in the prefs file.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 22, 2005, 04:17 PM
 
Originally posted by CharlesS:
I actually don't like this.

A hidden preference that lets any shell script get run invisibly when you log in? That's a great place for any piece of malware to hide the code to launch an invisible daemon on login, and most users would never know about it since the preference is hidden.

This should be in System Preferences, not hidden in the prefs file.
Umm... you're forgetting that you need the root password to edit and set that preference. If they have the root password... they don't need a silly login hook to screw you over
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 22, 2005, 04:59 PM
 
Originally posted by itistoday:
Umm... you're forgetting that you need the root password to edit and set that preference.
Not if you're logged in under an admin account. Since /Library/Preferences is writable by admin, the sudo in that command is really not necessary.

In fact, I just tried it, and my God! The LoginHook gets run as root! And you don't need root access to set this preference! This seems like a major exploit.

You can fix it by changing the preferences so that both /Library/Preferences and /Library/Preferences/com.apple.loginwindow.plist are read-only to the admin user, but then if you ever run Repair Permissions it will "fix" it so that admin has write access again...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 22, 2005, 05:06 PM
 
Originally posted by CharlesS:
Not if you're logged in under an admin account. Since /Library/Preferences is writable by admin, the sudo in that command is really not necessary.

In fact, I just tried it, and my God! The LoginHook gets run as root! And you don't need root access to set this preference! This seems like a major exploit.

You can fix it by changing the preferences so that both /Library/Preferences and /Library/Preferences/com.apple.loginwindow.plist are read-only to the admin user, but then if you ever run Repair Permissions it will "fix" it so that admin has write access again...
Oh wow, that is bad.
You should report this to apple.
     
bmedina
Mac Elite
Join Date: Jan 2000
Location: Seattle, WA, King
Status: Offline
Reply With Quote
Mar 22, 2005, 07:48 PM
 
Originally posted by CharlesS:
In fact, I just tried it, and my God! The LoginHook gets run as root! And you don't need root access to set this preference! This seems like a major exploit.
Yeah, that's probably not good. Are you sure that the actual script itself is run as root? That seems quite silly.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 22, 2005, 07:53 PM
 
Originally posted by bmedina:
Yeah, that's probably not good. Are you sure that the actual script itself is run as root? That seems quite silly.
If you don't believe me, try it yourself! I turned on SSH on my machine, and SSHed into it and watched the process list while I logged the machine into the GUI. The damn thing ran as root.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hal Itosis
Grizzled Veteran
Join Date: Mar 2004
Status: Offline
Reply With Quote
Mar 22, 2005, 08:29 PM
 
Originally posted by CharlesS:
The damn thing ran as root.
True. Loginhooks and logouthooks run as root. Not news. Not a bug.
How is this an exploit? Why would a script need to wait until login or
logout to do a dirty deed?

Both com.apple.loginwindow.plist and loginwindow.plist are owned by
system, and require admin passwords to be edited. If some malware asks
for a password and is given one... it could do *whatever* IMMEDIATELY.

Just in case com.apple.loginwindow.plist and loginwindow.plist AREN'T
owned by system (and read-only to everyone else) on your Mac, then set
them to be so. (Repairing permissions will NOT undo those settings).
-HI-
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Mar 22, 2005, 09:16 PM
 
Originally posted by CharlesS:
If you don't believe me, try it yourself! I turned on SSH on my machine, and SSHed into it and watched the process list while I logged the machine into the GUI. The damn thing ran as root.
CharlesS, have you reported this to Apple's security site?
weird wabbit
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 22, 2005, 09:46 PM
 
Originally posted by Hal Itosis:
True. Loginhooks and logouthooks run as root. Not news. Not a bug.
How is this an exploit? Why would a script need to wait until login or
logout to do a dirty deed?

Both com.apple.loginwindow.plist and loginwindow.plist are owned by
system, and require admin passwords to be edited. If some malware asks
for a password and is given one... it could do *whatever* IMMEDIATELY.

Just in case com.apple.loginwindow.plist and loginwindow.plist AREN'T
owned by system (and read-only to everyone else) on your Mac, then set
them to be so. (Repairing permissions will NOT undo those settings).
Dude, it's a problem if you can edit it by default on your main account. Not all viruses/worms do their dirty deed immediately. A lot of them just like to hibernate in your computer and do their "dirty deeds" for as long as they can, like acting as trojans, etc. This security hole would allow some malicious application to be executed in the background each time you start your computer as root! How is that not a security risk?? If there ever was a mac virus that spread, it would be childs play to make this script:
Code:
#!/bin/sh rm -rf /
Edit the prefs file, and you can say good-bye to your system the next time you login.
( Last edited by itistoday; Mar 22, 2005 at 09:51 PM. )
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 22, 2005, 09:52 PM
 
Originally posted by Hal Itosis:
True. Loginhooks and logouthooks run as root. Not news. Not a bug.
How is this an exploit? Why would a script need to wait until login or
logout to do a dirty deed?

Both com.apple.loginwindow.plist and loginwindow.plist are owned by
system, and require admin passwords to be edited. If some malware asks
for a password and is given one... it could do *whatever* IMMEDIATELY.

Just in case com.apple.loginwindow.plist and loginwindow.plist AREN'T
owned by system (and read-only to everyone else) on your Mac, then set
them to be so. (Repairing permissions will NOT undo those settings).
Why do people make these proclamations without trying it first?

Code:
136:~ baleeted$ cd /Library/Preferences 136:/Library/Preferences baleeted$ ls -l com.apple.loginwindow.plist -rw-r--r-- 1 root admin 587 22 Mar 19:45 com.apple.loginwindow.plist 136:/Library/Preferences baleeted$ defaults read /Library/Preferences/com.apple.loginwindow LoginHook 2005-03-22 19:46:21.248 defaults[1133] The domain/default pair of (/Library/Preferences/com.apple.loginwindow, LoginHook) does not exist 136:/Library/Preferences baleeted$ defaults write /Library/Preferences/com.apple.loginwindow LoginHook /exploit.sh 136:/Library/Preferences baleeted$ defaults read /Library/Preferences/com.apple.loginwindow LoginHook /exploit.sh 136:/Library/Preferences baleeted$ more com.apple.loginwindow.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple. com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>LoginHook</key> <string>/exploit.sh</string> ... other stuff ...
Yeah, the file is read-only. But, the folder that contains it, /Library/Preferences, is not. And the defaults command writes the files atomically, which means that it doesn't care what the old file's permissions are! It just deletes the file and writes a new one, which it can get away with since it has write access to the folder. But don't take my word for it! TRY IT!!! Then you will see that you in fact do not need the admin password, and this is very much an exploit.

Aaaaaand, now for the obligatory question:

Originally posted by theolein:
CharlesS, have you reported this to Apple's security site?
Yes I have. But you should too, because Apple sometimes seems to have a problem listening.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Mar 22, 2005, 10:05 PM
 
Originally posted by CharlesS:
...

Yes I have. But you should too, because Apple sometimes seems to have a problem listening.
Done. My memory is still fresh from the little fiasco of the launch services/file helpers/url vulnerability of last year where it took Apple over three months to react.

Granted, it is a local exploit, thank god, but it is very serious, IMO.
weird wabbit
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 22, 2005, 10:23 PM
 
Oh, and while you're at it, send them reports about the /Library/StartupItems vulnerability as well. By default, that folder doesn't exist, so any program running as admin can create it with whatever permissions it wants. And then it can put stuff inside, which will get run as root on the next reboot. The fix is to make a security update package that creates /Library/StartupItems and makes it read-only except by root. It's the easiest fix in the world to make, and it absolutely mystifies me why Apple hasn't fixed it even though it's been known for months...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
Mar 23, 2005, 12:22 AM
 
Originally posted by CharlesS:
Oh, and while you're at it, send them reports about the /Library/StartupItems vulnerability as well. By default, that folder doesn't exist, so any program running as admin can create it with whatever permissions it wants. And then it can put stuff inside, which will get run as root on the next reboot. The fix is to make a security update package that creates /Library/StartupItems and makes it read-only except by root. It's the easiest fix in the world to make, and it absolutely mystifies me why Apple hasn't fixed it even though it's been known for months...
Will do.
weird wabbit
     
khufuu
Registered User
Join Date: Aug 2002
Location: On my couch
Status: Offline
Reply With Quote
Mar 23, 2005, 03:13 AM
 
Originally posted by itistoday:
Hello, I need to run a shell script everytime I login to my computer, and I'd like it to run in the background. The script is a one liner that runs a command line program in the background. How do I do this?

Thanks for any suggestions.

Edit: I found one way: add the extension .command to the script and give it execution priveleges. However, this means that Terminal.app will open up on login. Is there a better way?
Umm.. Am I just missing something?

Can't you just create a .profile file in your home directory with whatever it is you want? That's what it's there for.
     
Moose
Senior User
Join Date: May 2001
Status: Offline
Reply With Quote
Mar 23, 2005, 09:23 AM
 
Originally posted by khufuu:
Umm.. Am I just missing something?

Can't you just create a .profile file in your home directory with whatever it is you want? That's what it's there for.
bash doesn't automatically exec when you log in.

But it does (by default) exec every time you open a new Terminal window.
     
khufuu
Registered User
Join Date: Aug 2002
Location: On my couch
Status: Offline
Reply With Quote
Mar 23, 2005, 11:11 AM
 
Originally posted by Moose:
bash doesn't automatically exec when you log in.

But it does (by default) exec every time you open a new Terminal window.
:-) Good to know.
     
Agent69
Mac Elite
Join Date: Jun 2000
Status: Offline
Reply With Quote
Mar 23, 2005, 03:01 PM
 
Itistoday,

One thing you could do is add a cron job to your personal crontab, using Vixie Cron's support for the special string "@reboot", which will make the command run everytime you reboot the computer.

Crontab(5) Manpage.
Agent69
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 23, 2005, 04:10 PM
 
Originally posted by Agent69:
Itistoday,

One thing you could do is add a cron job to your personal crontab, using Vixie Cron's support for the special string "@reboot", which will make the command run everytime you reboot the computer.

Crontab(5) Manpage.
Hmmm... interesting. I'll take a look, but so far the LoginHook is working. Also, I don't know if that means it'll execute before the network interfaces are up.
     
Hal Itosis
Grizzled Veteran
Join Date: Mar 2004
Status: Offline
Reply With Quote
Mar 23, 2005, 07:21 PM
 
Originally posted by CharlesS:
> Why do people make these proclamations without trying it first?
> [ . . . ]
> Yeah, the file is read-only. But, the folder that contains it,
> /Library/Preferences, is not. And the defaults command writes
> the files atomically, which means that it doesn't care what the
> old file's permissions are!
Sorry... "defaults" command?
That was not mentioned until you introduced it just now.
(Nice clear example btw, thanks much for the step-by-step).


Originally posted by CharlesS:
> It just deletes the file and writes a new one, which it can
> get away with since it has write access to the folder.
Huh? Hot damn, you're right! But hold the phone:
If there's a bug somewhere, it's the behavior of the
defaults write command. Try the same business with
pico (or some other editor) and the file -- owned by
system -- can't be touched. Not ownly (sic) does the
defaults command overwrite the file... it conveniently
changes the ownership as well!!!

Yes sir that's a bug alwrite (sic). But really...
it's the defaults write command which -- by NOT
requesting a password -- seemingly escalates the
user's privileges at the drop of a hat, and THAT'S
what (initially) facilitates this exploit to occur.

Would you agree (in part) with that assessment?
-HI-
     
Moose
Senior User
Join Date: May 2001
Status: Offline
Reply With Quote
Mar 23, 2005, 07:52 PM
 
Originally posted by Hal Itosis:
SYes sir that's a bug alwrite (sic). But really...
it's the defaults write command which -- by NOT
requesting a password -- seemingly escalates the
user's privileges at the drop of a hat, and THAT'S
what (initially) facilitates this exploit to occur.

Would you agree (in part) with that assessment?
No.

Because you can do that without using defaults(1). You could, for example, replicate defaults(1) behavior by using cp to copy the file to another, edit it how you want, then delete the old one and copy it back:
Code:
moose@portamoose(20):/Library/Preferences$ ls -l com.apple.loginwindow.plist -rw-r--r-- 1 root admin 112 Mar 22 22:14 com.apple.loginwindow.plist moose@portamoose(21):/Library/Preferences$ chmod 664 com.apple.loginwindow.plist chmod: com.apple.loginwindow.plist: Operation not permitted moose@portamoose(22):/Library/Preferences$ cp com.apple.loginwindow.plist com.apple.loginwindow.plist.temp moose@portamoose(23):/Library/Preferences$ ls -l com.apple.loginwindow.plist.temp -rw-r--r-- 1 moose admin 112 Mar 23 18:47 com.apple.loginwindow.plist.temp moose@portamoose(24):/Library/Preferences$ pico -w com.apple.loginwindow.plist.temp moose@portamoose(25):/Library/Preferences$ cp com.apple.loginwindow.plist.temp com.apple.loginwindow.plist cp: com.apple.loginwindow.plist: Permission denied moose@portamoose(26):/Library/Preferences$ rm com.apple.loginwindow.plist override rw-r--r-- root/admin for com.apple.loginwindow.plist? y moose@portamoose(27):/Library/Preferences$ cp com.apple.loginwindow.plist.temp com.apple.loginwindow.plist moose@portamoose(28):/Library/Preferences$
If you can, as a non-root user, without entering a password, create a file in a directory that results in things being executed as root, this is a bug in how the system's set up. Not a bug in defaults(1).
     
Hal Itosis
Grizzled Veteran
Join Date: Mar 2004
Status: Offline
Reply With Quote
Mar 23, 2005, 08:12 PM
 
Originally posted by Moose:
override rw-r--r-- root/admin for com.apple.loginwindow.plist? y


Well... at least rm asked nicely.



I suppose a scripted version would bypass the whole y/n
prompt routine with your basic rm -f . . .



Okay then, "Houston" [oops, I mean]:
"Cupertino... we have a problem."

-HI-
     
Moose
Senior User
Join Date: May 2001
Status: Offline
Reply With Quote
Mar 23, 2005, 08:27 PM
 
Originally posted by Hal Itosis:
Well... at least rm asked nicely.
Strictly speaking, rm doesn't even have to ask. Deleting a file doesn't actually touch the file. It just removes its entry from the directory. And, given that you have write access to that directory....
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 23, 2005, 08:58 PM
 
Originally posted by Hal Itosis:
Sorry... "defaults" command?
That was not mentioned until you introduced it just now.
(Nice clear example btw, thanks much for the step-by-step).
The link to Bombich's website was using the defaults command, but he used sudo defaults. My point was that the command worked worked without sudo.

Huh? Hot damn, you're right! But hold the phone:
If there's a bug somewhere, it's the behavior of the defaults write command. Try the same business with pico (or some other editor) and the file -- owned by system -- can't be touched. Not ownly (sic) does the defaults command overwrite the file... it conveniently changes the ownership as well!!!
As others have said, you don't need defaults to do this. It's just the most convenient way.

Yes sir that's a bug alwrite (sic). But really... it's the defaults write command which -- by NOT requesting a password -- seemingly escalates the user's privileges at the drop of a hat, and THAT'S what (initially) facilitates this exploit to occur.

Would you agree (in part) with that assessment?
No. The defaults command didn't escalate the user's privileges at all. It's only because we have write access to that folder that this is possible. The only way defaults would be able to get around permissions without a password would be if it were setuid root, and it's not.

Anyway, to fix this, just make /Library/Preferences read-only:

sudo chown root:admin /Library/Preferences
sudo chmod 755 /Library/Preferences

Also, making sure the file itself is read-only won't hurt:

sudo chown root:admin /Library/Preferences/com.apple.loginwindow.plist
sudo chmod 644 /Library/Preferences/com.apple.loginwindow.plist

If you ever repair permissions, you have to do this again, since Repair Permissions will make /Library/Preferences writable again.
( Last edited by CharlesS; Mar 23, 2005 at 09:05 PM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hal Itosis
Grizzled Veteran
Join Date: Mar 2004
Status: Offline
Reply With Quote
Mar 23, 2005, 09:47 PM
 
Let's throw in a :
sudo chflags uchg /Library/Preferences/com.apple.loginwindow.plist
for good measure.

-HI-
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 23, 2005, 09:49 PM
 
Originally posted by Hal Itosis:
Let's throw in a :
sudo chflags uchg /Library/Preferences/com.apple.loginwindow.plist
for good measure.

While that would work, you shouldn't need it if you made /Library/Preferences read-only.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Mar 23, 2005, 09:55 PM
 
Originally posted by CharlesS:
While that would work, you shouldn't need it if you made /Library/Preferences read-only.
You know, I don't know about that. If you make it read-only you could screw up some applications that put stuff in there (I'm looking through mine and can see several, like BBEdit's serial number, and I don't remember BBEdit asking me for my root pass when I put the serial in).
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Apr 18, 2005, 08:40 PM
 
Hey, I think Apple *fixed* this with the recent software/security updates. Or maybe I'm just crazy... Does the LoginHook work for anybody? Cause it stopped working for me.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Apr 19, 2005, 01:24 PM
 
Originally Posted by itistoday
Hey, I think Apple *fixed* this with the recent software/security updates. Or maybe I'm just crazy... Does the LoginHook work for anybody? Cause it stopped working for me.
Doesn't work anymore for me either. What a lame way to fix this. All they had to do was to make the LoginHook run as the user you were logging in as, instead of root.

Especially since /Library/StartupItems still doesn't exist by default, so any app running as admin can just create that, stick whatever they want in there, and get root access anyway.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
asdasd
Forum Regular
Join Date: Apr 2003
Location: Santa Clara
Status: Offline
Reply With Quote
Apr 19, 2005, 01:35 PM
 
I always thought that the loginhook was designed to be run as the loggedin user - right?

This has been there since the Next days. It presumably has legacy implications in removal ( i,e, sys admins would find it broken).
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Apr 19, 2005, 02:12 PM
 
Originally Posted by asdasd
I always thought that the loginhook was designed to be run as the loggedin user - right?
In 10.3.8, it ran as root every time I tried it.

Not to say that couldn't have been fixed without throwing the whole mechanism out the window. Oh well...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Mac Write
Mac Elite
Join Date: Aug 2000
Location: Vancouver B.C.
Status: Offline
Reply With Quote
Apr 19, 2005, 04:26 PM
 
I also need to run a port forward to get around my ISP's port 25 blocking. They only allow you to use their crappy insecure slow unreliable SMTP server. Maybe I should wait and work on it when Tiger comes out instead.
Get busy living or get busy dying
--Stephen King
     
Ganesha
Senior User
Join Date: Jul 2002
Location: Arizona Wasteland
Status: Offline
Reply With Quote
Apr 19, 2005, 08:21 PM
 
For those of you who need to run suid/sgid scripts on 10.3.9 or later...

Apple did not remove the functionality. Apple just added a toggle to turn it on and off, and set the default to off. If you want/need to turn it on, just toggle the sysctl 'kern.sugid_scripts'.
     
piracy
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Apr 19, 2005, 08:35 PM
 
edit
     
itistoday  (op)
Professional Poster
Join Date: Oct 2001
Status: Offline
Reply With Quote
Apr 19, 2005, 09:11 PM
 
Originally Posted by Ganesha
For those of you who need to run suid/sgid scripts on 10.3.9 or later...

Apple did not remove the functionality. Apple just added a toggle to turn it on and off, and set the default to off. If you want/need to turn it on, just toggle the sysctl 'kern.sugid_scripts'.
Wow, never even heard of this command. So is this what I'm supposed to do?
Code:
sudo sysctl -w 'kern.sugid_scripts'=1
     
Jellytussle
Dedicated MacNNer
Join Date: Jan 2001
Location: Badfort
Status: Offline
Reply With Quote
Apr 20, 2005, 05:55 AM
 
I'm just about to try out loginhooks under 10.3.9, since i use them at pretty much every client i set up (perhaps 5000 boxes?). But as far as security under 10.3.=<8 goes, remember that the defaults system works on the idea of domains, and works from the specific to the general. This means that if you set the loginhook in root's preferences, this will override the setting in /L/P, thus preventing your malware scenario above. I have just tested this on a 10.3.8 client.
You see, my friends, pirates are the key. - thalo
     
Jellytussle
Dedicated MacNNer
Join Date: Jan 2001
Location: Badfort
Status: Offline
Reply With Quote
Apr 20, 2005, 06:09 AM
 
Originally Posted by CharlesS
In 10.3.8, it ran as root every time I tried it.

Not to say that couldn't have been fixed without throwing the whole mechanism out the window. Oh well...
Well, i don't know if i'm not testing what others are testing, but i've just updated my test box to 10.3.9 with all available updates, and i still have full login and logout hook functionality. Both scripts run as the root user.
You see, my friends, pirates are the key. - thalo
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 12:12 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,