Hi,
I have a NKE project that needs a user space daemon to be running to get
information back from the user.
I have this working and everything, and have a daemon launched for each
individual user that runs the program.
I have my user space daemon with these privileges, 4755, which means the
setuid bit is set for my daemon executable so that it can elevate itself to
perform a process id lookup. My question is what does Apple/Security feel
about my application having the setuid bit set?
Thanks,
Matt
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com
This email sent to bsdarchive (AT) developershed (DOT) com

Jan 3, 2006, at 8:31 AM, matt jaffa wrote:

I have a NKE project that needs a user space daemon to be running
to get information back from the user.
I have this working and everything, and have a daemon launched for
each individual user that runs the program.

I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it can
elevate itself to perform a process id lookup. My question is what
does Apple/Security feel about my application having the setuid bit
set?

Matt,

Firstly, many thanks for picking a sensible architecture for your
application.

I'm a little confused about "perform a process id lookup" though.
What are you trying to do, and what specific interface(s) are you
using that require privilege?

As a general rule, having your daemon run setuid inside the user's
environment is discouraged.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

So my NKE gets the pid of the process sending information out. I send this
pid to a daemon that will lookup that process path based on the pid using
the sysctl KERN_PRC methods. But this sysctl will fail if it is looking up
the path on a process owned by root. So my daemon has to be running as root
to get this info, and I want to be able to have a daemon for each logged in
user so the UI can be displayed to the current active user.

I could spawn a process with popen ( ps ) and gather the path that way, but
ps will be spawned everytime I get a new pid my NKE doesn't know about. Is
this a bad thing? Spawning a lot of little "ps" just to get this
information.

Thanks,
Matt

1/3/06, Mike Smith <drivers (AT) mu (DOT) orgwrote:
--
Jan 3, 2006, at 8:31 AM, matt jaffa wrote:

I have a NKE project that needs a user space daemon to be running
to get information back from the user.
I have this working and everything, and have a daemon launched for
each individual user that runs the program.

I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it can
elevate itself to perform a process id lookup. My question is what
does Apple/Security feel about my application having the setuid bit
set?

Matt,

Firstly, many thanks for picking a sensible architecture for your
application.

I'm a little confused about "perform a process id lookup" though.
What are you trying to do, and what specific interface(s) are you
using that require privilege?

As a general rule, having your daemon run setuid inside the user's
environment is discouraged.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Unfortunately p_comm will not work in my case. I will be displaying to the
user what application is trying to send data out and they will get to choose
whether to accept it or reject it. So the full path is required so the user
knows where the application is located exactly.

Is there any other way in my daemon can accomplish this as non-root? I like
Brian's question:

"Is there some other way for a non-root process to get the full exec
path of any other process (including root owned)?"

Thanks,
Matt

1/3/06, Brian Bergstrand <freebsd (AT) classicalguitar (DOT) netwrote:

PGP SIGNED MESSAGE
Hash: SHA1
--
Jan 3, 2006, at 1:15 PM, Mike Smith wrote:
--
Jan 3, 2006, at 8:31 AM, matt jaffa wrote:
>
>I have a NKE project that needs a user space daemon to be running
>to get information back from the user.
>I have this working and everything, and have a daemon launched for
>each individual user that runs the program.
>>
>I have my user space daemon with these privileges, 4755, which
>means the setuid bit is set for my daemon executable so that it
>can elevate itself to perform a process id lookup. My question is
>what does Apple/Security feel about my application having the
>setuid bit set?
>
Matt,

Firstly, many thanks for picking a sensible architecture for your
application.

I'm a little confused about "perform a process id lookup" though.
What are you trying to do, and what specific interface(s) are you
using that require privilege?

I think he means that KERN_PRCARGS returns an error when you try to
get info about processes running with a different uid than the
calling application (unless you are root). In my case I only care
about the full exec path and not the program args.

However, KERN_PRC_PID can be used to get the process struct of any
process from a non-root app and the kp_proc.p_comm member will give
you a limited name (16 bytes and not the full path). The full path is
very useful for use as an arg to LSCopyDisplayNameForURL(), but pcomm
suffices as a fall back.

Is there some other way for a non-root process to get the full exec
path of any other process (including root owned)?
--
Here's my function that wraps this all up (there's a little C, but
nothing that can't be substituted easily):

static id path_for_pid(int32_t pid, BL *isFullPath)
{
size_t arglen;
int mib[4] = {CTL_KERN, 0, 0, 0};

NSString *path = nil;
mib[1] = KERN_PRCARGS2;
mib[2] = pid;
arglen = argmax; // KERN_ARGMAX
char *cmdargs = malloc(argmax+1);
if (cmdargs && 0 == sysctl(mib, 3, cmdargs, &arglen, NULL, 0)) {
*(cmdargs+(arglen-1)) = '\0'; // Just in case
// argc is first for KERN_PRCARGS2, so skip the size of an int
// the command path is next
path = [NSString stringWithCString:(cmdargs + sizeof(int))
encoding:NSUTF8StringEncoding];
* isFullPath = YES;
} else if (EINVAL == errno) {
// sysctl prevents non-root procs from accessing other users
proc args
mib[1] = KERN_PRC;
mib[2] = KERN_PRC_PID;
mib[3] = pid;
struct kinfo_proc p;
arglen = sizeof(p);
if (0 == sysctl(mib, 4, &p, &arglen, NULL, 0))
path = [NSString
encoding:NSUTF8StringEncoding];
* isFullPath = N;
}
if (cmdargs)
free(cmdargs);

return (path);
}

HTH.

Brian Bergstrand
<PGP Key ID: 0xB6C7B6A2

PGP SIGNATURE
Version: GnuPG v1.4.1 (Darwin)

8E0XQru5B+Ab8JxAm04aT48=
=9KNI
PGP SIGNATURE

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote:

>Jan 3, 2006, at 8:31 AM, matt jaffa wrote:
>>
I have a NKE project that needs a user space daemon to be running
to get information back from the user.
I have this working and everything, and have a daemon launched
for each individual user that runs the program.

I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it
can elevate itself to perform a process id lookup. My question
is what does Apple/Security feel about my application having the
setuid bit set?
>>
>I'm a little confused about "perform a process id lookup" though.
>What are you trying to do, and what specific interface(s) are you
>using that require privilege?
>
I think he means that KERN_PRCARGS returns an error when you try
to get info about processes running with a different uid than the
calling application (unless you are root). In my case I only care
about the full exec path and not the program args.

You should not depend on any path information associated with a
running process.

However, KERN_PRC_PID can be used to get the process struct of any
process from a non-root app and the kp_proc.p_comm member will give
you a limited name (16 bytes and not the full path). The full path
is very useful for use as an arg to LSCopyDisplayNameForURL(), but
pcomm suffices as a fall back.

Is there some other way for a non-root process to get the full exec
path of any other process (including root owned)?

No. In addition, there is no guarantee that the path is correct,
that the file that is present at that path is the one being executed,
that the path is acccessible or even valid for your context, or that
there even was a path to begin with.

Any information you get from p_comm or the KERN_PRCARGS sysctl is
purely informative, and you should not depend on it in any fashion
whatsoever.

If you need a guaranteed association between running processes and
filesystem identities you need to look at a higher level, and accept
that there are processes and tasks which will fall outside the scope
of the information available at that level.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

PGP SIGNED MESSAGE
Hash: SHA1

Jan 3, 2006, at 3:47 PM, Mike Smith wrote:

Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote:

Jan 3, 2006, at 8:31 AM, matt jaffa wrote:

I have a NKE project that needs a user space daemon to be
running to get information back from the user.
I have this working and everything, and have a daemon launched
for each individual user that runs the program.

I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it
can elevate itself to perform a process id lookup. My question
is what does Apple/Security feel about my application having the
setuid bit set?

I'm a little confused about "perform a process id lookup"
though. What are you trying to do, and what specific interface
(s) are you using that require privilege?
>>
>I think he means that KERN_PRCARGS returns an error when you try
>to get info about processes running with a different uid than the
>calling application (unless you are root). In my case I only care
>about the full exec path and not the program args.
>
You should not depend on any path information associated with a
running process.
>
>However, KERN_PRC_PID can be used to get the process struct of
>any process from a non-root app and the kp_proc.p_comm member will
>give you a limited name (16 bytes and not the full path). The full
>path is very useful for use as an arg to LSCopyDisplayNameForURL
>(), but pcomm suffices as a fall back.
>>
>Is there some other way for a non-root process to get the full
>exec path of any other process (including root owned)?
>
No. In addition, there is no guarantee that the path is correct,
that the file that is present at that path is the one being
executed, that the path is acccessible or even valid for your
context, or that there even was a path to begin with.

Any information you get from p_comm or the KERN_PRCARGS sysctl is
purely informative, and you should not depend on it in any fashion
whatsoever.

If you need a guaranteed association between running processes and
filesystem identities you need to look at a higher level, and
accept that there are processes and tasks which will fall outside
the scope of the information available at that level.

= Mike

I know and accept all of that - for my app, the information is purely
informative to the user. There are no permanent associations/
assumptions made about the path. It's that pcomm can contain a
truncated name and the user (not my app) may not be able to associate
the truncated name with an actual application. Most of the time,
pcomm suffices so it's not a big problem.

Brian Bergstrand
<PGP Key ID: 0xB6C7B6A2

PGP SIGNATURE
Version: GnuPG v1.4.1 (Darwin)

/X8vro2VcXhPjgZqso2umlE=
=y86Y
PGP SIGNATURE

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 3, 2006, at 2:09 PM, Brian Bergstrand wrote:

PGP SIGNED MESSAGE
Hash: SHA1
--
Jan 3, 2006, at 3:47 PM, Mike Smith wrote:
>
>>
>Jan 3, 2006, at 12:40 PM, Brian Bergstrand wrote:
>>
Jan 3, 2006, at 8:31 AM, matt jaffa wrote:

I have a NKE project that needs a user space daemon to be
running to get information back from the user.
I have this working and everything, and have a daemon launched
for each individual user that runs the program.

I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it
can elevate itself to perform a process id lookup. My question
is what does Apple/Security feel about my application having the
setuid bit set?

I'm a little confused about "perform a process id lookup"
though. What are you trying to do, and what specific interface
(s) are you using that require privilege?

I think he means that KERN_PRCARGS returns an error when you try
to get info about processes running with a different uid than the
calling application (unless you are root). In my case I only care
about the full exec path and not the program args.
>>
>You should not depend on any path information associated with a
>running process.
>>
However, KERN_PRC_PID can be used to get the process struct of
any process from a non-root app and the kp_proc.p_comm member will
give you a limited name (16 bytes and not the full path). The full
path is very useful for use as an arg to LSCopyDisplayNameForURL
(), but pcomm suffices as a fall back.

Is there some other way for a non-root process to get the full
exec path of any other process (including root owned)?
>>
>No. In addition, there is no guarantee that the path is correct,
>that the file that is present at that path is the one being
>executed, that the path is acccessible or even valid for your
>context, or that there even was a path to begin with.
>>
>Any information you get from p_comm or the KERN_PRCARGS sysctl is
>purely informative, and you should not depend on it in any fashion
>whatsoever.
>>
>If you need a guaranteed association between running processes and
>filesystem identities you need to look at a higher level, and
>accept that there are processes and tasks which will fall outside
>the scope of the information available at that level.
>>
>= Mike
>>
>
I know and accept all of that - for my app, the information is
purely informative to the user. There are no permanent associations/
assumptions made about the path. It's that pcomm can contain a
truncated name and the user (not my app) may not be able to
associate the truncated name with an actual application. Most of the
time, pcomm suffices so it's not a big problem.

Brian Bergstrand

When a process is started after a vfork or fork plus an execve, the
kauth subsystem gets a callback for KAUTH_FILEP_EXEC with the vp to
kauth_scope_fileop listeners. There is a small performance penalty on
a number of paths for having any listeners in this scope (this is
documented in the source code for kern_authorization.c, which I
suggest you understand if you are going to attempt to use this to
solve your problem).

This would let you associate the path (obtained via the KPI vn_getpath
() on the vnode) that was used to look up with a PID (using proc_pid()
on the current process). You'd then communicate this association to
your daemon, for it to cache. The vn_getpath is a tricky KPI; it's
final argument is both an in and an out value, so you will need to
reset it to your buffer size on each call (which should be PATH_MAX
from <sys/syslimits.h>).

You would not get any notification via kauth when the process went
away (for complex reasons having to do with the inability of some
network FS's to rename open files, without non-standard extensions to
their protocols), so you would need to either keep a potentially
pretty big cache of the information, or occasionally poll in user
space using the kill(pid, 0) existence test for processes (-1 &
ENENT=no process, -1 & EPERM=process exists, but you can't signal it,
0=process exists and you can signal it, but no signal was actually
sent) to clean out the stale cache entries.

As Mike pointed out though, this would only get you to the point of
you knowing what the file that was there was named before the attempt
to contact the network, so what file's there at the time you want to
check and looks "mostly harmless" is not necessarily actually the code
that's running.

To answer your original question, though, the security guys generally
frown on SUID/SGID anything, even if it's an ordinary user the thing
impersonates.
-- Terry

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 3, 2006, at 12:14 PM, matt jaffa wrote:

So my NKE gets the pid of the process sending information out. I
send this pid to a daemon that will lookup that process path based
on the pid using the sysctl KERN_PRC methods. But this sysctl will
fail if it is looking up the path on a process owned by root. So my
daemon has to be running as root to get this info, and I want to be
able to have a daemon for each logged in user so the UI can be
displayed to the current active user.

I could spawn a process with popen ( ps ) and gather the path that
way, but ps will be spawned everytime I get a new pid my NKE
doesn't know about. Is this a bad thing? Spawning a lot of little
"ps" just to get this information.

Don't use popen, as it invokes the shell and that puts you at risk
(the shell may be invalid, or its startup files may have been coopted).

However, given that you're about to draw UI and block waiting for the
user, running ps (use a custom output format to override any
defaults, and invoke ps via an explicit path) is not going to cause
any observable overhead.

Even if your application supports saved rules, running ps once per
application is not a major hit.

ps can still be wrong, but it is more likely to both be right and to
be maintained in such a fashion that it prints reasonable output.

= Mike

Thanks,
Matt
--
1/3/06, Mike Smith <drivers (AT) mu (DOT) orgwrote:

Jan 3, 2006, at 8:31 AM, matt jaffa wrote:

I have a NKE project that needs a user space daemon to be running
to get information back from the user.
I have this working and everything, and have a daemon launched for
each individual user that runs the program.

I have my user space daemon with these privileges, 4755, which
means the setuid bit is set for my daemon executable so that it can
elevate itself to perform a process id lookup. My question is what
does Apple/Security feel about my application having the setuid bit
set?

Matt,

Firstly, many thanks for picking a sensible architecture for your
application.

I'm a little confused about "perform a process id lookup" though.
What are you trying to do, and what specific interface(s) are you
using that require privilege?

As a general rule, having your daemon run setuid inside the user's
environment is discouraged.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Le 04 Jan 2006, 08:27, Mike Smith a :

Jan 3, 2006, at 12:14 PM, matt jaffa wrote:
>
>So my NKE gets the pid of the process sending information out. I send
>this pid to a daemon that will lookup that process path based on the
>pid using the sysctl KERN_PRC methods. But this sysctl will fail if
>it is looking up the path on a process owned by root. So my daemon
>has to be running as root to get this info, and I want to be able to
>have a daemon for each logged in user so the UI can be displayed to
>the current active user.
>*
>I could spawn a process with popen ( ps ) and gather the path that
>way, but ps will be spawned everytime I get a new pid my NKE doesn't
>know about. Is this a bad thing? Spawning a lot of little "ps" just
>to get this information.
Don't use popen, as it invokes the shell and that puts you at risk
(the shell may be invalid, or its startup files may have been
coopted).

However, given that you're about to draw UI and block waiting for the
user, running ps (use a custom output format to override any defaults,
and invoke ps via an explicit path) is not going to cause any
observable overhead.

Even if your application supports saved rules, running ps once per
application is not a major hit.

ps can still be wrong, but it is more likely to both be right and to
be maintained in such a fashion that it prints reasonable output.

I would say that ps is _always_ wrong when the process has been
launched using a relative path since a relative path can match multiple
absolute paths.

As for the suid thing, why not just used a StartupItem or a launchd
thing? Bootstrap context is usually the nirvana for daemon needing to
communicate with a kernel extension.

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 4, 2006, at 2:58 AM, Stephane Sudre wrote:


>ps can still be wrong, but it is more likely to both be right and
>to be maintained in such a fashion that it prints reasonable output.
>>
>
I would say that ps is _always_ wrong when the process has been
launched using a relative path since a relative path can match
multiple absolute paths.

In this case, ps is no more wrong than anything else.

As for the suid thing, why not just used a StartupItem or a launchd
thing? Bootstrap context is usually the nirvana for daemon needing
to communicate with a kernel extension.

As Matt clearly pointed out, he needs to present UI to the user; this
can't be done legitimately from the bootstrap session. And it
doesn't help solve this problem.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 4, 2006, at 5:58 PM, Mike Smith wrote:

Jan 4, 2006, at 2:58 AM, Stephane Sudre wrote:
--
ps can still be wrong, but it is more likely to both be right and
to be maintained in such a fashion that it prints reasonable output.

>>
>I would say that ps is _always_ wrong when the process has been
>launched using a relative path since a relative path can match
>multiple absolute paths.
>>
>
In this case, ps is no more wrong than anything else.

The KAuth API would give an absolute path AFAIK.

>
>As for the suid thing, why not just used a StartupItem or a
>launchd thing? Bootstrap context is usually the nirvana for daemon
>needing to communicate with a kernel extension.
>>
>
As Matt clearly pointed out, he needs to present UI to the user;
this can't be done legitimately from the bootstrap session. And it
doesn't help solve this problem.

This can be done from a bootstrap session. You just have to launch a
helper tool for the UI.

If the UI does not need to be really complex, you can also use a
CFUserNotification dialog.

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 4, 2006, at 9:34 AM, Stephane wrote:
Jan 4, 2006, at 5:58 PM, Mike Smith wrote:
>Jan 4, 2006, at 2:58 AM, Stephane Sudre wrote:
ps can still be wrong, but it is more likely to both be right and
to be maintained in such a fashion that it prints reasonable
output.

I would say that ps is _always_ wrong when the process has been
launched using a relative path since a relative path can match
multiple absolute paths.
>>
>In this case, ps is no more wrong than anything else.
>
The KAuth API would give an absolute path AFAIK.

The approach I described using a kauth listener to get the path
information depends on the directory lookup name cache information.

The problem with this approach, which I think Mike is alluding to, is
that between the time you cache the information in the user space
daemon, and he time you use it to present to the user a choice, the
target of the path that was cached may have changed. Even if you
specifically go out of your way in user space, and also pass dev_t and
ino_t information, verifying it immediately before presentation in the
UI -- there's no real way to programatically lock a path so that its
components are not permitted to change, without seriously obstructing
the ability of the system to get actual work done.

So it's basically a snapshot, however you approach it.

Using the output of the "ps" program is actually the recommended
method of getting information which is the least prone to breakage in
future versions of the S going forward. For the most part, I
personally hate the KERN_* sysctl's - they are data interfaces, and
therefore subject to becoming potentially stale.

If you use the output of "ps" with appropriate field selection
arguments to get only the data you want, then we can change things out
from under you, and your application will still work, since "ps" is
revised in lockstep with the kernel itself.

As Mike also pointed out in another message, "ps" is K for this
particular case, since the issue only comes up when specific network
traffic is being allowed/denied via a user interaction. The "ps"
program itself won't trigger this in the normal case, since it's run
from local disks, and has no network dependencies of its own.

As for the suid thing, why not just used a StartupItem or a
launchd thing? Bootstrap context is usually the nirvana for daemon
needing to communicate with a kernel extension.

>>
>As Matt clearly pointed out, he needs to present UI to the user;
>this can't be done legitimately from the bootstrap session. And it
>doesn't help solve this problem.
>
This can be done from a bootstrap session. You just have to launch a
helper tool for the UI.

If the UI does not need to be really complex, you can also use a
CFUserNotification dialog.

We discourage this - "can't be done *legitimately*" [emphasis
mine] - because you never know that what happens to work right now
will continue to work the same way in some far off future. There's a
big difference between "can be done this way" and "should be done this
way".
-- Terry

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 4, 2006, at 9:34 AM, Stephane wrote:

Jan 4, 2006, at 5:58 PM, Mike Smith wrote:
>
>
>Jan 4, 2006, at 2:58 AM, Stephane Sudre wrote:
>>
>>
ps can still be wrong, but it is more likely to both be right
and to be maintained in such a fashion that it prints reasonable
output.

I would say that ps is _always_ wrong when the process has been
launched using a relative path since a relative path can match
multiple absolute paths.

>>
>In this case, ps is no more wrong than anything else.
>>
>
The KAuth API would give an absolute path AFAIK.

The KAUTH API is useless here; there is no association between the
authorisation check for executability on a vnode (where you would be
able to fetch the looked-up path for the vnode) and a process which
just *happens* to be associated with a task which just *happens* to
have the text segment from said file mapped in a fashion consistent
with a binary being executed.

There is no guarantee that a process is a result of launching an
executable. There is no guarantee that any file mapped into the task
address space associated with a process has anything to do with the
path given to the exec(2) system call. There is no guarantee that
there even *was* an exec(2) system call.

Jan 4, 2006, at 1:47 PM, Terry Lambert wrote:
The problem with this approach, which I think Mike is alluding to,
is that between the time you cache the information in the user
space daemon, and he time you use it to present to the user a
choice, the target of the path that was cached may have changed.
Even if you specifically go out of your way in user space, and also
pass dev_t and ino_t information, verifying it immediately before
presentation in the UI -- there's no real way to programatically
lock a path so that its components are not permitted to change,
without seriously obstructing the ability of the system to get
actual work done.

This is one facet of the issue; it's a specific instance of a generic
problem.

As Mike also pointed out in another message, "ps" is K for this
particular case, since the issue only comes up when specific
network traffic is being allowed/denied via a user interaction.
The "ps" program itself won't trigger this in the normal case,
since it's run from local disks, and has no network dependencies of
its own.

I was actually referring to the comparatively low overhead of running
ps vs. displaying UI, but the above is also good point. Note that
it's important to specify the minimal set of fields for ps to
display, as some symbolic information may result in nested network
traffic leading to deadlock.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

04 Jan 2006, at 22:47, Terry Lambert wrote:

Jan 4, 2006, at 9:34 AM, Stephane wrote:
>Jan 4, 2006, at 5:58 PM, Mike Smith wrote:
Jan 4, 2006, at 2:58 AM, Stephane Sudre wrote:
ps can still be wrong, but it is more likely to both be right and
to be maintained in such a fashion that it prints reasonable
output.

I would say that ps is _always_ wrong when the process has been
launched using a relative path since a relative path can match
multiple absolute paths.

In this case, ps is no more wrong than anything else.
>>
>The KAuth API would give an absolute path AFAIK.
>
The approach I described using a kauth listener to get the path
information depends on the directory lookup name cache information.

The problem with this approach, which I think Mike is alluding to, is
that between the time you cache the information in the user space
daemon, and he time you use it to present to the user a choice, the
target of the path that was cached may have changed. Even if you
specifically go out of your way in user space, and also pass dev_t and
ino_t information, verifying it immediately before presentation in the
UI -- there's no real way to programatically lock a path so that its
components are not permitted to change, without seriously obstructing
the ability of the system to get actual work done.

So it's basically a snapshot, however you approach it.

Affirmative, but I would rather get an absolute snapshot than a
relative one.

Using the output of the "ps" program is actually the recommended
method of getting information which is the least prone to breakage in
future versions of the S going forward. For the most part, I
personally hate the KERN_* sysctl's - they are data interfaces, and
therefore subject to becoming potentially stale.

I agree that the sysctl thing is a problem since for instance the ps
code using sysctl from Panther is not working on Tiger.

If you use the output of "ps" with appropriate field selection
arguments to get only the data you want, then we can change things out
from under you, and your application will still work, since "ps" is
revised in lockstep with the kernel itself.

As Mike also pointed out in another message, "ps" is K for this
particular case, since the issue only comes up when specific network
traffic is being allowed/denied via a user interaction. The "ps"
program itself won't trigger this in the normal case, since it's run
from local disks, and has no network dependencies of its own.

Yet the problem with using ps is that you are relying on an external
tool which may change in the future and to which you do not have access
as changes are being made. Example: the ps source code for Tiger was
not available until the release of Tiger.

An extreme case could also be that the ps tool is not installed on the
computer.

Anyway, the main problem IMH is that S X/Darwin is lacking either a
true and trustful API to get this information or a proc folder (even
though I think I saw such a folder in one case (maybe it was on S X
Server)).

>This can be done from a bootstrap session. You just have to launch a
>helper tool for the UI.
>>
>If the UI does not need to be really complex, you can also use a
>CFUserNotification dialog.
>
We discourage this - "can't be done *legitimately*" [emphasis
mine] - because you never know that what happens to work right now
will continue to work the same way in some far off future. There's a
big difference between "can be done this way" and "should be done this
way".

I'm not sure to see where the illegitimate part lies in the
CFUserNotification API or launching a helper tool. Can you shed some
light on this?

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 5, 2006, at 2:26 AM, Stephane Sudre wrote:

>If you use the output of "ps" with appropriate field selection
>arguments to get only the data you want, then we can change things
>out from under you, and your application will still work, since
>"ps" is revised in lockstep with the kernel itself.
>>
>As Mike also pointed out in another message, "ps" is K for this
>particular case, since the issue only comes up when specific
>network traffic is being allowed/denied via a user interaction.
>The "ps" program itself won't trigger this in the normal case,
>since it's run from local disks, and has no network dependencies
>of its own.
>
Yet the problem with using ps is that you are relying on an
external tool which may change in the future and to which you do
not have access as changes are being made. Example: the ps source
code for Tiger was not available until the release of Tiger.

You don't need the ps source code; you just invoke ps directly. The
interface to ps-the-program is much less likely to change than the
kernel's internal data structures.

An extreme case could also be that the ps tool is not installed on
the computer.

Then the system is not Mac S X.

Anyway, the main problem IMH is that S X/Darwin is lacking either
a true and trustful API to get this information or a proc folder
(even though I think I saw such a folder in one case (maybe it was
on S X Server)).

There is no such interface because the information you want cannot be
reliably returned; an interface that returns wrong information is
worse than no interface at all.

= Mike

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 5, 2006, at 2:26 AM, Stephane Sudre wrote:
04 Jan 2006, at 22:47, Terry Lambert wrote:
>Using the output of the "ps" program is actually the recommended
>method of getting information which is the least prone to breakage
>in future versions of the S going forward. For the most part, I
>personally hate the KERN_* sysctl's - they are data interfaces, and
>therefore subject to becoming potentially stale.
>
I agree that the sysctl thing is a problem since for instance the ps
code using sysctl from Panther is not working on Tiger.

It's not a supported API, it is an SPI. Applications are not intended
to use it. System utilities are permitted to use it, so long as they
are revised in lockstep with the base S. Applications - no matter
*who* writes them - are expected to talk to the system utilities, and
get the information in a nice, safe, abstract, and nominally future-
proof way, instead of going fishing. Any other use of it is "at your
own substantial risk of your software breaking, maybe as soon as the
next software update", and strongly discouraged.


>If you use the output of "ps" with appropriate field selection
>arguments to get only the data you want, then we can change things
>out from under you, and your application will still work, since
>"ps" is revised in lockstep with the kernel itself.
>>
>As Mike also pointed out in another message, "ps" is K for this
>particular case, since the issue only comes up when specific
>network traffic is being allowed/denied via a user interaction.
>The "ps" program itself won't trigger this in the normal case,
>since it's run from local disks, and has no network dependencies of
>its own.
>
Yet the problem with using ps is that you are relying on an external
tool which may change in the future and to which you do not have
access as changes are being made. Example: the ps source code for
Tiger was not available until the release of Tiger.

This is true; however, this complaint is almost completely mitigated
by the fact that there are international and defacto standards for the
"ps" program, and as long as neither of those standards change, you
can be pretty darn sure that standards conforming use of the program
will continue to work as expected.

The reason we suggested that you use specific output formatting and
process-of-interest constraint options, rather than groveling through
the default unqualified and unconstrained output, was *specifically*
to insulate you from potential changes to those standards or the
tool's output outside the scope of control of standards, or any bug
fixes we might have to do.

An extreme case could also be that the ps tool is not installed on
the computer.

Then having it available becomes a prerequisite for your software.

This may be inconvenient, but it's less inconvenient than, say,
needing to install your application as SUID root, like "ps" itself, or
your SUID application crashing or being used as a gateway to
compromise system integrity, or dozens of other worse things than
having "ps" available to people who already have shell access to the
machine.

Anyway, the main problem IMH is that S X/Darwin is lacking either
a true and trustful API to get this information or a proc folder
(even though I think I saw such a folder in one case (maybe it was
on S X Server)).

Welcome to the world of systems tools.

There really isn't any UNIX or UNIX-like system in existence that
doesn't have some form of data interface that requires changes to
system utilities, or user applications that think (or act like) they
are system utilities. This includes things like the ill-designed
"procfs" on many systems. And if an administrator takes away "ps",
they will surely take away "/proc", so that people can't write or
download their own copy of "ps" to override the administrators
decision, unless "/proc" is also disabled - at which point you are in
the same boat.

The bottom line is that, if you insist on using data interfaces - even
supported ones, which these are not - instead of using procedural
interfaces to talk to programs that use data interfaces, to insulate
yourself from any unforeseen S changes well, you are probably
going to eventually be unhappy when your application suddenly stops
working.

This can be done from a bootstrap session. You just have to launch
a helper tool for the UI.

If the UI does not need to be really complex, you can also use a
CFUserNotification dialog.
>>
>We discourage this - "can't be done *legitimately*" [emphasis
>mine] - because you never know that what happens to work right now
>will continue to work the same way in some far off future. There's
>a big difference between "can be done this way" and "should be done
>this way".
>
I'm not sure to see where the illegitimate part lies in the
CFUserNotification API or launching a helper tool. Can you shed some
light on this?

Using it or launching a helper tool that uses it from the bootstrap
session is unsupported. If you think about it, it should be obvious
to you why this is the case.
-- Terry

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

1/5/06, Terry Lambert <tlambert (AT) apple (DOT) comwrote:
Jan 5, 2006, at 2:26 AM, Stephane Sudre wrote:
04 Jan 2006, at 22:47, Terry Lambert wrote:
>Using the output of the "ps" program is actually the recommended
>method of getting information which is the least prone to breakage
>in future versions of the S going forward. For the most part, I
>personally hate the KERN_* sysctl's - they are data interfaces, and
>therefore subject to becoming potentially stale.
>
I agree that the sysctl thing is a problem since for instance the ps
code using sysctl from Panther is not working on Tiger.

It's not a supported API, it is an SPI. Applications are not intended
to use it. System utilities are permitted to use it, so long as they
are revised in lockstep with the base S. Applications - no matter
*who* writes them - are expected to talk to the system utilities, and
get the information in a nice, safe, abstract, and nominally future-
proof way, instead of going fishing. Any other use of it is "at your
own substantial risk of your software breaking, maybe as soon as the
next software update", and strongly discouraged.
>
>
>If you use the output of "ps" with appropriate field selection
>arguments to get only the data you want, then we can change things
>out from under you, and your application will still work, since
>"ps" is revised in lockstep with the kernel itself.
>>
>As Mike also pointed out in another message, "ps" is K for this
>particular case, since the issue only comes up when specific
>network traffic is being allowed/denied via a user interaction.
>The "ps" program itself won't trigger this in the normal case,
>since it's run from local disks, and has no network dependencies of
>its own.
>
Yet the problem with using ps is that you are relying on an external
tool which may change in the future and to which you do not have
access as changes are being made. Example: the ps source code for
Tiger was not available until the release of Tiger.

This is true; however, this complaint is almost completely mitigated
by the fact that there are international and defacto standards for the
"ps" program, and as long as neither of those standards change, you
can be pretty darn sure that standards conforming use of the program
will continue to work as expected.

The reason we suggested that you use specific output formatting and
process-of-interest constraint options, rather than groveling through
the default unqualified and unconstrained output, was *specifically*
to insulate you from potential changes to those standards or the
tool's output outside the scope of control of standards, or any bug
fixes we might have to do.
--
An extreme case could also be that the ps tool is not installed on
the computer.

Then having it available becomes a prerequisite for your software.

This may be inconvenient, but it's less inconvenient than, say,
needing to install your application as SUID root, like "ps" itself, or
your SUID application crashing or being used as a gateway to
compromise system integrity, or dozens of other worse things than
having "ps" available to people who already have shell access to the
machine.
--
Anyway, the main problem IMH is that S X/Darwin is lacking either
a true and trustful API to get this information or a proc folder
(even though I think I saw such a folder in one case (maybe it was
on S X Server)).

Welcome to the world of systems tools.

There really isn't any UNIX or UNIX-like system in existence that
doesn't have some form of data interface that requires changes to
system utilities, or user applications that think (or act like) they
are system utilities. This includes things like the ill-designed
"procfs" on many systems. And if an administrator takes away "ps",
they will surely take away "/proc", so that people can't write or
download their own copy of "ps" to override the administrators
decision, unless "/proc" is also disabled - at which point you are in
the same boat.

The bottom line is that, if you insist on using data interfaces - even
supported ones, which these are not - instead of using procedural
interfaces to talk to programs that use data interfaces, to insulate
yourself from any unforeseen S changes well, you are probably
going to eventually be unhappy when your application suddenly stops
working.
>
>
>
This can be done from a bootstrap session. You just have to launch
a helper tool for the UI.

If the UI does not need to be really complex, you can also use a
CFUserNotification dialog.
>>
>We discourage this - "can't be done *legitimately*" [emphasis
>mine] - because you never know that what happens to work right now
>will continue to work the same way in some far off future. There's
>a big difference between "can be done this way" and "should be done
>this way".
>
I'm not sure to see where the illegitimate part lies in the
CFUserNotification API or launching a helper tool. Can you shed some
light on this?

Using it or launching a helper tool that uses it from the bootstrap
session is unsupported. If you think about it, it should be obvious
to you why this is the case.

-- Terry

Delurk:

see my current favourite tech note, aka "argh, where were you a few
years ago but we figured it out",
<>
-H.

Lurk:

Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (Darwin-kernel (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com