Exploitable security hole in TunnelRunner.c

[Eric Warnke]

Since I like SSHKeychain and want to get the last few really annoying
bugs worked out I started reviewing the code. Here are some major
security issues with TunnerRunner.c and another reason that you should
never suid-root an application.

SECURITY BUG #1: Kill any process

Lines 41-46
if(argc == 3 && strstr(argv[1], "-k") != NULL) {
setuid(geteuid());

kill(atoi(argv[2]), SIGTERM);
exit(0);
}

Because it's suid-root you can kill ANY process in the system.

SECURITY BUG #2: Privilege escalation

Lines 53-56
if(strstr(argv[1], "ssh") == NULL)
{
exit(1);
}

Lines 132-137
/* Execute ssh. */
if(execv(argv[0], argv) == -1)
{
fprintf(stderr, "execv() failed (%s)\n", strerror(errno));
exit(1);
}

As long as your command has the name ssh in it somewhere
TunnelRunner.c will happily run it as root. This is basically a blank
slate exploit.

BUG #3: Weird code

Lines 149-153
for(;;)
{
/* Read until we get EOF. */
for(;;)
{

Lines 191-192
}
}

Two endless loops? In side these loops I can find no reason why
TunnerRunner even needs to be running. I'm probably missing something
obvious, but why does the parent even need to continue running? If
the parent doesn't need to continue running then why does tunnel
runner even need to fork in the first place, it could close the files
and execv.


The security is easy to fix, quit SSHKeychain and chmod 755
TunnelRunner. I have also chown'ed it as well.

Cheers,
Eric




----------------------
Eric Warnke
518-396-5277
***@gmail.com

[Tim Cutts]

Post by Eric Warnke
SECURITY BUG #2: Privilege escalation
Lines 53-56
if(strstr(argv[1], "ssh") == NULL)
{
exit(1);
}

Yowser. Basically, I think the only way to make TunnelRunner secure
is to hardcode the ssh binary it runs (presumably to /usr/bin/ssh)
and not allow it to accept a command to run on the commandline.
Probably a fairly simple fix to make, but if I remember rightly it
will need multiple versions of the code depending on the version of
Mac OS X, because in some cases the system ssh doesn't work properly,
and so Bart supplied a version with SSHKeychain. But still, should
be easy to code up.

Tim

[Eric Warnke]

That would also be a huge hack. TunnelRunner should use sudo where
necessary to grant privileges. It also does not fix the problem that
TunnelRunner can currently kill any process in the system.

The only reason TunnelRunner is suid anyways ( and requires
installation ) is so that privileged ports can be forwarded. I think
we need to accept that, for now, the risk far outweighs the benefit.
People can always accept/ignore the risk and suid-root TunnelRunner
all by themselves.

-Eric

Post by Tim Cutts
Yowser. Basically, I think the only way to make TunnelRunner secure
is to hardcode the ssh binary it runs (presumably to /usr/bin/ssh)
and not allow it to accept a command to run on the commandline.
Probably a fairly simple fix to make, but if I remember rightly it
will need multiple versions of the code depending on the version of
Mac OS X, because in some cases the system ssh doesn't work properly,
and so Bart supplied a version with SSHKeychain. But still, should
be easy to code up.
Tim
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Bart Matthaei]

Hi Eric,

thanks for the heads up. TunnelRunner is a bit of a mess, I agree.
I'll fix up a new release asap.

Cheers,

Bart

Post by Eric Warnke
Since I like SSHKeychain and want to get the last few really annoying
bugs worked out I started reviewing the code. Here are some major
security issues with TunnerRunner.c and another reason that you should
never suid-root an application.
SECURITY BUG #1: Kill any process
Lines 41-46
if(argc == 3 && strstr(argv[1], "-k") != NULL) {
setuid(geteuid());
kill(atoi(argv[2]), SIGTERM);
exit(0);
}
Because it's suid-root you can kill ANY process in the system.
SECURITY BUG #2: Privilege escalation
Lines 53-56
if(strstr(argv[1], "ssh") == NULL)
{
exit(1);
}
Lines 132-137
/* Execute ssh. */
if(execv(argv[0], argv) == -1)
{
fprintf(stderr, "execv() failed (%s)\n", strerror(errno));
exit(1);
}
As long as your command has the name ssh in it somewhere
TunnelRunner.c will happily run it as root. This is basically a blank
slate exploit.
BUG #3: Weird code
Lines 149-153
for(;;)
{
/* Read until we get EOF. */
for(;;)
{
Lines 191-192
}
}
Two endless loops? In side these loops I can find no reason why
TunnerRunner even needs to be running. I'm probably missing something
obvious, but why does the parent even need to continue running? If
the parent doesn't need to continue running then why does tunnel
runner even need to fork in the first place, it could close the files
and execv.
The security is easy to fix, quit SSHKeychain and chmod 755
TunnelRunner. I have also chown'ed it as well.
Cheers,
Eric
----------------------
Eric Warnke
518-396-5277
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Eric Warnke]

Sounds good.

I'm still getting farmiliarized with the code and I have never done
OSX programming so if I say something stupid, bear with me.

1) Is tunner runner even a necessary item anymore? It looks like all
it really does is terminate the ssh connection if there are errors on
the output... that can't be handled directly in SSHKeychain?

2) It looks like the -k option is never actually used anywhere in the
codebase and could be removed. This would solve one bug.

3) I really hope that for privilege escalation you find a way to do
that with sudo or other OSX friendly trick. If it were with sudo
people can always add a line to their sudoers to make sure it will
never prompt them.

4) The double loop can go away, as well as the check for child=0 (
parent ) since both other conditions are already accounted for.

Cheers,
Eric

Post by Bart Matthaei
Hi Eric,
thanks for the heads up. TunnelRunner is a bit of a mess, I agree.
I'll fix up a new release asap.
Cheers,
Bart

Post by Eric Warnke
Since I like SSHKeychain and want to get the last few really annoying
bugs worked out I started reviewing the code. Here are some major
security issues with TunnerRunner.c and another reason that you should
never suid-root an application.
SECURITY BUG #1: Kill any process
Lines 41-46
if(argc == 3 && strstr(argv[1], "-k") != NULL) {
setuid(geteuid());
kill(atoi(argv[2]), SIGTERM);
exit(0);
}
Because it's suid-root you can kill ANY process in the system.
SECURITY BUG #2: Privilege escalation
Lines 53-56
if(strstr(argv[1], "ssh") == NULL)
{
exit(1);
}
Lines 132-137
/* Execute ssh. */
if(execv(argv[0], argv) == -1)
{
fprintf(stderr, "execv() failed (%s)\n", strerror(errno));
exit(1);
}
As long as your command has the name ssh in it somewhere
TunnelRunner.c will happily run it as root. This is basically a blank
slate exploit.
BUG #3: Weird code
Lines 149-153
for(;;)
{
/* Read until we get EOF. */
for(;;)
{
Lines 191-192
}
}
Two endless loops? In side these loops I can find no reason why
TunnerRunner even needs to be running. I'm probably missing something
obvious, but why does the parent even need to continue running? If
the parent doesn't need to continue running then why does tunnel
runner even need to fork in the first place, it could close the files
and execv.
The security is easy to fix, quit SSHKeychain and chmod 755
TunnelRunner. I have also chown'ed it as well.
Cheers,
Eric
----------------------
Eric Warnke
518-396-5277
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

--
Ambrero Software
http://www.ambrero.nl/
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Bart Matthaei]

Hi Eric,

Post by Eric Warnke
1) Is tunner runner even a necessary item anymore? It looks like all
it really does is terminate the ssh connection if there are errors on
the output... that can't be handled directly in SSHKeychain?

It was introduced to make things a little easier and less error prone
on the SSHKeychain side.

Post by Eric Warnke
2) It looks like the -k option is never actually used anywhere in the
codebase and could be removed. This would solve one bug.

It is used to kill a root spawned TunnelRunner process. Since
SSHKeychain runs as your own user
and TunnelRunner runs as root, we can't kill TunnelRunner from
SSHKeychain directly.

This was a quick hack and I'm still working on a better solution.

Post by Eric Warnke
3) I really hope that for privilege escalation you find a way to do
that with sudo or other OSX friendly trick. If it were with sudo
people can always add a line to their sudoers to make sure it will
never prompt them.

Using sudo is not an option, since you can't use that inside an
application (where would the prompt go?).

Post by Eric Warnke
4) The double loop can go away, as well as the check for child=0 (
parent ) since both other conditions are already accounted for.

The double loops were probably introduced in a faulty merge.

Cheers,

Bart

[Eric Warnke]

Bart,

I think the best solution is to use the authorization services when
someone requests a privileged port operation. This way you preserve
the drag and drop nature of SSHKeychain as well as being able to suid
root the TunnelRunner when it becomes necessary, but not before.

Here is a link to the Apple documentation of the feature in question.

http://developer.apple.com/documentation/Security/Conceptual/authorization_concepts/index.html#//apple_ref/doc/uid/TP30000995

I don't think suid TunnerRunner should be the default, but only
enabled if the user is seeking to tunnel a privileged port. Looking
at the documentation seems to indicate that this should be fairly
simple to do. TunnerRunner will have the additional option to repair
itself if it's not root/suid and the user asks for a privileged port
forward.

Oh, another simple fix is their is no reason to swap pointers for
argv[], you can call execv with argv[1] and argc-1 to achieve the same
effect.

I really do want to get involved in development so f you wanted me to
take a swing at fixing up TunnelRunner I can give it a shot. I'm new
to svn, what branch should I be working off of to get the latest and
greatest work?

Cheers,
Eric

Post by Bart Matthaei
Hi Eric,

Post by Eric Warnke
1) Is tunner runner even a necessary item anymore? It looks like all
it really does is terminate the ssh connection if there are errors on
the output... that can't be handled directly in SSHKeychain?

It was introduced to make things a little easier and less error prone
on the SSHKeychain side.

Post by Eric Warnke
2) It looks like the -k option is never actually used anywhere in the
codebase and could be removed. This would solve one bug.

It is used to kill a root spawned TunnelRunner process. Since
SSHKeychain runs as your own user
and TunnelRunner runs as root, we can't kill TunnelRunner from
SSHKeychain directly.
This was a quick hack and I'm still working on a better solution.

Post by Eric Warnke
3) I really hope that for privilege escalation you find a way to do
that with sudo or other OSX friendly trick. If it were with sudo
people can always add a line to their sudoers to make sure it will
never prompt them.

Using sudo is not an option, since you can't use that inside an
application (where would the prompt go?).

Post by Eric Warnke
4) The double loop can go away, as well as the check for child=0 (
parent ) since both other conditions are already accounted for.

The double loops were probably introduced in a faulty merge.
Cheers,
Bart
--
Ambrero Software
http://www.ambrero.nl/
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Bart Matthaei]

Hi Eric,

you're more than welcome to fix it! :-)

All new stuff is in trunk: http://svn.sshkeychain.org/repos/trunk/

If you need commit access, drop me a line off the list.

Regards,

Bart

Post by Eric Warnke
Bart,
I think the best solution is to use the authorization services when
someone requests a privileged port operation. This way you preserve
the drag and drop nature of SSHKeychain as well as being able to suid
root the TunnelRunner when it becomes necessary, but not before.
Here is a link to the Apple documentation of the feature in question.
http://developer.apple.com/documentation/Security/Conceptual/
authorization_concepts/index.html#//apple_ref/doc/uid/TP30000995
I don't think suid TunnerRunner should be the default, but only
enabled if the user is seeking to tunnel a privileged port. Looking
at the documentation seems to indicate that this should be fairly
simple to do. TunnerRunner will have the additional option to repair
itself if it's not root/suid and the user asks for a privileged port
forward.
Oh, another simple fix is their is no reason to swap pointers for
argv[], you can call execv with argv[1] and argc-1 to achieve the same
effect.
I really do want to get involved in development so f you wanted me to
take a swing at fixing up TunnelRunner I can give it a shot. I'm new
to svn, what branch should I be working off of to get the latest and
greatest work?
Cheers,
Eric

Post by Bart Matthaei
Hi Eric,

Post by Eric Warnke
1) Is tunner runner even a necessary item anymore? It looks like all
it really does is terminate the ssh connection if there are
errors on
the output... that can't be handled directly in SSHKeychain?

It was introduced to make things a little easier and less error prone
on the SSHKeychain side.

Post by Eric Warnke
2) It looks like the -k option is never actually used anywhere in the
codebase and could be removed. This would solve one bug.

It is used to kill a root spawned TunnelRunner process. Since
SSHKeychain runs as your own user
and TunnelRunner runs as root, we can't kill TunnelRunner from
SSHKeychain directly.
This was a quick hack and I'm still working on a better solution.

Post by Eric Warnke
3) I really hope that for privilege escalation you find a way to do
that with sudo or other OSX friendly trick. If it were with sudo
people can always add a line to their sudoers to make sure it will
never prompt them.

Using sudo is not an option, since you can't use that inside an
application (where would the prompt go?).

Post by Eric Warnke
4) The double loop can go away, as well as the check for child=0 (
parent ) since both other conditions are already accounted for.

The double loops were probably introduced in a faulty merge.
Cheers,
Bart
--
Ambrero Software
http://www.ambrero.nl/
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

--
----------------------
Eric Warnke
518-396-5277
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Jeremy Reichman]

Whatever the solution is, I'd like to see one where system administrators
who want to deploy SSHKeychain can do so cleanly -- preferably without
requiring it to be run first, and without it having to modify its own
on-disk permissions.

Some of us deploy SSHKeychain to multi-user systems via tools like Radmind
(radmind.org). Some also may want to tripwire our systems.

This is perhaps where the utility of the installer package shows through?

Thanks!

[Dustin J. Mitchell]

Post by Jeremy Reichman
Whatever the solution is, I'd like to see one where system administrators
who want to deploy SSHKeychain can do so cleanly -- preferably without
requiring it to be run first, and without it having to modify its own
on-disk permissions.
Some of us deploy SSHKeychain to multi-user systems via tools like Radmind
(radmind.org). Some also may want to tripwire our systems.
This is perhaps where the utility of the installer package shows through?

It should be straightforward to do both -- the installer sets things up
correctly, but autorepair is supported for drag-n-drop installs.

Dustin

[Eric Warnke]

Looking over the options it's not pretty.

1) suid utility like TunnelRunner: This will work, but allows *ANY*
user of the system to subvert privileged ports. If this is the intent
that people have I don't see the benefit of suid TunnelRunner vs just
setting ssh suid root ( man ssh ). I don't care how secure I make
TunnelRunner it's an issue waiting to happen.

2) Use of the authentication services to run TunnelRunner as root.
This would do the same thing, but would prompt the user every time ( 5
minute timeout ). This would not require setting anything suid but
would be more annoying for some people.

Personally I don't think SSHkeychain/TunnelRunner should be suid-root
by default. There are just too many security questions. I would
prefer that it never had suid-root permissions, but it appears as
though that might require the administrator dialog to activate some
tunnels. Authentications would last for 5 minutes.

If I could get the authentication / authorization to last forever (
for that user ) it might be a more useful item. Even if it's only
once per session it might be useful as well. TunnelRunner would still
be run as root, but only those with administrative privs would be able
to capture ports below 1024.



Is there enough of a demand for forwarding ports lower than 1024 to
make these security issues worth while?

Cheers,
Eric

[Tim Cutts]

Post by Eric Warnke
2) Use of the authentication services to run TunnelRunner as root.
This would do the same thing, but would prompt the user every time ( 5
minute timeout ). This would not require setting anything suid but
would be more annoying for some people.

But it only happens when you establish the tunnel. I don't know
about you, but I only establish my tunnels once or twice a day.

Post by Eric Warnke
Personally I don't think SSHkeychain/TunnelRunner should be suid-root
by default.

I agree.

Post by Eric Warnke
There are just too many security questions. I would
prefer that it never had suid-root permissions, but it appears as
though that might require the administrator dialog to activate some
tunnels. Authentications would last for 5 minutes.

... but the tunnel, once established, lasts for hours, so I don't see
this being a problem.

Post by Eric Warnke
Is there enough of a demand for forwarding ports lower than 1024 to
make these security issues worth while?

I don't know. That's worth a straw poll. I don't forward tunnels
below port 1024, and none of my users do either. The services I ssh
tunnel routinely are SSH, SMTP, IMAP, LDAP, MySQL, and web proxy,
none of which require the local tunnelled port to be below 1024.

Tim

[Jay]

Post by Tim Cutts

Post by Eric Warnke
There are just too many security questions. I would
prefer that it never had suid-root permissions, but it appears as
though that might require the administrator dialog to activate some
tunnels. Authentications would last for 5 minutes.

... but the tunnel, once established, lasts for hours, so I don't see
this being a problem.

Because of this, I agree as well.

I had to write a launchd script today and while googling came across
an this apple page:

http://developer.apple.com/macosx/launchd.html

Which had this VERY interesting tidbit:

"Of particular interest is that launchd can run a job as a non-root
user, but still bind it to a privileged port. This removes one common
reason to run daemons as root."

Does this mean that you could use launchctl to load a plist setting
up tunnelrunner or ssh to bind to a privileged port?

- Jay

[Eric Warnke]

Assuming that forwarding privileged ports is needed, I guess the straw
poll should be...

Should non-admins be able to establish low port forwards?

Should we just prompt to establish low forwards?


I've been thinking about the problem some more and have come up with
another option.

1) Write a small utility designed to be run as root or suid root which
can forward a low port to a higher port. The benefit of a utility
like this is that it's dirt simple and would allow for it to drop root
as soon as it has bound to the low port. This would mean an easy
audit trail and no reason for TunnelRunner to be killing root owned
pid's.

Either way, the documentation and discussion shed some interesting
light on the subject.

1) You should not put suid-root apps in the bundle. I guess one
problem is that FileVault does not respect suid. There are also some
sticky security issues as well. They recommend using
/Library/Application Support/<app> for storing helpers since you need
administrative privileges to modify files in that directory so their
is less likelihood of tampering with the app or permissions.

Anyways, I think we can come to an acceptable solution soon.

Cheers,
Eric

[Eric Warnke]

Post by Jay
Does this mean that you could use launchctl to load a plist setting
up tunnelrunner or ssh to bind to a privileged port?
- Jay

Probably not because ssh is not designed to treat stdin as it's
source. This is the reason I'm looking at a small app that can
forward one local port to another. The helper app drops root as soon
as possible ( becoming the user again ) and ssh would never need to be
run as root.

Cheers,
Eric

[Eric Warnke]

Hmmmm....

After reading the docs, launchd could be far more useful that it
initially appears. It would only help for locally forwarded ports and
would not be applicable to dynamic ports ( I don't think so at least
).

It would also solve one of my last issues since the ssh connection
would be triggered upon use as long as launchd was running and this is
a HUGE advantage for us mobile users since the launch on wake /
startup is flakey in a WiFi setting.

Cheers,
Eric

Post by Eric Warnke

Post by Jay
Does this mean that you could use launchctl to load a plist setting
up tunnelrunner or ssh to bind to a privileged port?
- Jay

Probably not because ssh is not designed to treat stdin as it's
source. This is the reason I'm looking at a small app that can
forward one local port to another. The helper app drops root as soon
as possible ( becoming the user again ) and ssh would never need to be
run as root.
Cheers,
Eric

[Bart Matthaei]

The only problem is that launchd is only available on 10.4 and up.
But that shouldn't be a problem.
Nobody uses < 10.4 anyway. ;-)

Cheers,

Bart

Post by Eric Warnke
Hmmmm....
After reading the docs, launchd could be far more useful that it
initially appears. It would only help for locally forwarded ports and
would not be applicable to dynamic ports ( I don't think so at least
).
It would also solve one of my last issues since the ssh connection
would be triggered upon use as long as launchd was running and this is
a HUGE advantage for us mobile users since the launch on wake /
startup is flakey in a WiFi setting.
Cheers,
Eric

Post by Eric Warnke

Post by Jay
Does this mean that you could use launchctl to load a plist setting
up tunnelrunner or ssh to bind to a privileged port?
- Jay

Probably not because ssh is not designed to treat stdin as it's
source. This is the reason I'm looking at a small app that can
forward one local port to another. The helper app drops root as soon
as possible ( becoming the user again ) and ssh would never need to be
run as root.
Cheers,
Eric

_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Eric Warnke]

Ok, more research and some success. launchd is turning out to be VERY handy.

If I create a tunnel.plist in ~/Library/LaunchAgents with the
following text, I have a persistent tunnel that is triggered (ssh not
running all the time) and survived reboots.

<?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>Label</key>
<string>com.test.three</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/ssh</string>
<string>***@ssh-host</string>
<string>--</string>
<string>nc</string>
<string>smtp-host</string>
<string>25</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>inetdCompatibility</key>
<dict>
<key>Wait</key>
<false/>
</dict>
<key>UserName</key>
<string>user</string>
<key>Sockets</key>
<dict>
<key>Listeners</key>
<dict>
<key>SockServiceName</key>
<string>2525</string>
</dict>
</dict>
<key>EnvironmentVariables</key>
<dict>
<key>SSH_AUTH_SOCK</key>
<string>/tmp/501/SSHKeychain.socket</string>
</dict>
</dict>
</plist>

Now before we jump to conclusions I can confirm that you still need
administrative access to use launchd to capture low ports. But, like
above, you only need access ONCE to enable the tunnel and then it will
just be there. The only issue that might be hairy is that it's tied
to the ssh-auth that is not launched until sshkeychain is run. The
other issue is that you also need administrative access to turn the
tunnel off, I don't think this is a huge deal, but just putting it out
there.

The example above is an auto-triggered local tunnel, but the other
should be supported as well. SSHKeychain continues to be the
authentication agent, but tunnelrunner can go by-by as all handling of
tunnels is run by launchd.



Can we have a show of hands.... how many people would be SOL if we use
launchd? (Tiger+ only)

Is it worth holding up development?

Cheers,
Eric

[Aaron Jacobs]

Post by Eric Warnke
Can we have a show of hands.... how many people would be SOL if we use
launchd? (Tiger+ only)
Is it worth holding up development?

With Leopard coming out in two months, I don't think there's anything
wrong with dropping support for Panther (and so on). Remember that
Tiger has been out for almost two and a half years; those who are
content with sticking to a two and a half year old OS can content
themselves with sticking to an old release of SSHKeychain.

In my opinion, Mac developers tend to be way too timid in cutting
support for older OS releases. Two and a half years is a hell of a
long time in the computer world, and especially with OS X there are
lots of developer benefits to going with newer releases.

Aaron

[Dustin J. Mitchell]

Post by Aaron Jacobs
With Leopard coming out in two months, I don't think there's anything
wrong with dropping support for Panther (and so on). Remember that
Tiger has been out for almost two and a half years; those who are
content with sticking to a two and a half year old OS can content
themselves with sticking to an old release of SSHKeychain.

I agree with the above, and I think it's in line with decisions other
Mac software vendors are making (for example, Adium 1.1 requires OS
10.4).

Post by Aaron Jacobs
In my opinion, Mac developers tend to be way too timid in cutting
support for older OS releases. Two and a half years is a hell of a
long time in the computer world, and especially with OS X there are
lots of developer benefits to going with newer releases.

But I have to argue with this -- just about any other operating system
has better backward-compatibility than Mac OS X. For example, Windows
2000 has been out for almost 7 years, yet most software for Windows will
still run on it. Most UNIXy open source software (Apache, Amanda,
MySQL, Linux, you name it) will run on hardware that's as old as I am.
Apple users really have an unusually *short* upgrade curve, particularly
given the enormously expensive and fairly disruptive upgrades.

Dustin

[Aaron Jacobs]

Post by Dustin J. Mitchell
But I have to argue with this -- just about any other operating system
has better backward-compatibility than Mac OS X. For example, Windows
2000 has been out for almost 7 years, yet most software for Windows will
still run on it. Most UNIXy open source software (Apache, Amanda,
MySQL, Linux, you name it) will run on hardware that's as old as I am.
Apple users really have an unusually *short* upgrade curve,
particularly
given the enormously expensive and fairly disruptive upgrades.

In my opinion it's that short upgrade curve and lesser lack of
concern for backwards compatibility that has allowed OS X and the
applications written for OS X to come so far in such a short time.
Remember how much 10.1 sucked?

I certainly wouldn't want to trade all the features available to make
the lives of developers easier in 10.4 and 10.5 for an Apple-mandated
focus on backwards compatibility with earlier versions of OS X.
Remember, developers can choose not to use those features if they
think it will get them more users and it's worth the hassle. This
way the market decides, basically.

[Bart Matthaei]

Post by Eric Warnke
Ok, more research and some success. launchd is turning out to be VERY handy.
If I create a tunnel.plist in ~/Library/LaunchAgents with the
following text, I have a persistent tunnel that is triggered (ssh not
running all the time) and survived reboots.

Cool stuff :-)

My only concern is failure reporting. How does launchd handle that?
TunnelRunner takes into account if the ssh session worked, but
forwarding of the port failed
(because the port is in use, for instance):

[snip]

Post by Eric Warnke
Can we have a show of hands.... how many people would be SOL if we use
launchd? (Tiger+ only)
Is it worth holding up development?

Don't let backwards compatibility hold you down ;-) This way we can
drop the Panther ssh binary too.

Cheers,

Bart

[Eric Warnke]

Post by Bart Matthaei
My only concern is failure reporting. How does launchd handle that?
TunnelRunner takes into account if the ssh session worked, but
forwarding of the port failed

Good question... turns out you can have launchd dump stderr to a file.

So if I make a launchd request where it will be unable to bind to the
port I would see this in the error log.

bind: Address already in use

<key>StandardErrorPath</key>
<string>/tmp/tunnel-err2.txt</string>

So that's covered. My next, and I think last, issue is getting
launchd to tell me what's actually RUNNING and or not. It's fond of
showing me all the possible things, but right now there is no way to
tell if it's running or not. In theory 'launchctl list' should do
this, but it does not.

The investigation continues.

Cheers,
Eric

[Bart Matthaei]

A feature that can't be implemented if we go with launchd is 'Start
tunnels on demand'.
I was thinking about binding to tunneled ports in SSHKeychain,
listening in on connections, and as soon as a connection
to that port is opened, the corresponding tunnel is launched.

Post by Eric Warnke

Post by Bart Matthaei
My only concern is failure reporting. How does launchd handle that?
TunnelRunner takes into account if the ssh session worked, but
forwarding of the port failed

Good question... turns out you can have launchd dump stderr to a file.
So if I make a launchd request where it will be unable to bind to the
port I would see this in the error log.
bind: Address already in use
<key>StandardErrorPath</key>
<string>/tmp/tunnel-err2.txt</string>
So that's covered. My next, and I think last, issue is getting
launchd to tell me what's actually RUNNING and or not. It's fond of
showing me all the possible things, but right now there is no way to
tell if it's running or not. In theory 'launchctl list' should do
this, but it does not.
The investigation continues.
Cheers,
Eric
_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Eric Warnke]

Bart,

launchd can do this... if you look back at the example that's exactly
what I have done. The only thing is that the remote ssh server must
have access to the utility nc. I recently also tried the old style of
spawning ssh to listen and that works as well.

Cheers,
Eric

Post by Bart Matthaei
A feature that can't be implemented if we go with launchd is 'Start
tunnels on demand'.
I was thinking about binding to tunneled ports in SSHKeychain,
listening in on connections, and as soon as a connection
to that port is opened, the corresponding tunnel is launched.

[Bart Matthaei]

Sorry, my bad :-)

Post by Eric Warnke
Bart,
launchd can do this... if you look back at the example that's exactly
what I have done. The only thing is that the remote ssh server must
have access to the utility nc. I recently also tried the old style of
spawning ssh to listen and that works as well.
Cheers,
Eric

Post by Bart Matthaei
A feature that can't be implemented if we go with launchd is 'Start
tunnels on demand'.
I was thinking about binding to tunneled ports in SSHKeychain,
listening in on connections, and as soon as a connection
to that port is opened, the corresponding tunnel is launched.

_______________________________________________
developers mailing list
http://www.sshkeychain.org/cgi-bin/mailman/listinfo/developers

[Tim Cutts]

Post by Bart Matthaei
Using sudo is not an option, since you can't use that inside an
application (where would the prompt go?).

Isn't there a framework that provides similar functionality? Lots of
OS X applications prompt for an admin password if they need to
escalate privileges, and this actually seems to use sudo internally.
Carbon Copy Cloner does this, for example, and so do several parts of
OS X itself.

Tim