-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 5:38 AM +0900 10/18/01, Jim Cooper wrote:
>the NetInfo manager is just one thing the is likely to be opened and
>on the desktop in sudo mode... the function is built in
>however...
>
>Any of these third party apps like snard or Pseudo which can open
>apps as superuser in GUI
>
>or if you sudo {{open BBEdit}}
>and then close the terminal and open from the apple menu with BBEdit
>in the front
>
>same thing .....a terminal with root logged in...
>
>and BBEdit *did not* show up in the list of apps generated by the
>"find" method that Scott Anguish presented at Stepwise.
I'm not sure from your mail if you have the Unix model of permissions
down or not. If so, then ignore this.
Unix permissions are based on a simple user/group/world model. You
can read/write/execute something if you are the right user or belong
to the right group (you can belong to multiple groups)--as specified
by a files permissions. This isn't as flexible as an ACL (Access
Control List) model, but there it is.
There's one special user called root (actually, you can have multiple
root accounts, but we won't go into that). Root can do anything on
the machine, regardless of permissions.
Since running around in a root shell all the time is dangerous (you
might accidentally do something in the wrong place, or to the wrong
thing, like "rm -r * .bak" instead of "rm -r *.bak" for instance, and
create an unbootable machine) the sudo command was created. The sudo
command lets you run a single command line program as root. But in
order to do so you have to belong to a select list of users and/or
groups. sudo won't do this for just anyone. See "man sudo" and
"/etc/sudoers". sudo further lets you restrict users by "class" and
limit what each class of user can do. This gives you something that
acts kind of like an ACL system. You can restrict certain users to
running only certain commands. So you might assign email
administration to a particular user, and they could use sudo to run
some email administration commands but nothing else. By default the
first user in MacOS X is a member of the admin group, and can run
sudo to do anything they want, including run a shell (at which point
you can obviously run anything else). (If you think about it, you'll
realize that "sudo" must be setuid root to do everything it does.)
There is another way that an application can be run as root. That's
if it as the "setuid" bit set. That tells the operating system that
the application should be run with the permissions of the user that
"owns" the file (back to the unix permissions there). There's also a
"setgid" bit that does the same thing for groups--for instance email
programs might be setgid "mail" on a typical unix system so that
they'd have permission to write to the mail spool directory. This is
how NetInfo Manager gets to be root.
GUI applications on MacOS X can ask to become root. That's when you
enter your password and they can now do an install or whatever it is
they need to do. Logically they are doing a "sudo", although I don't
know the actual mechanism.
Now. When a program is run with root permissions, and it invokes
another program, that program also runs as root. (Otherwise a root
shell would not be very useful.) However if a program is run as root
because it is setuid it can check and find out who really ran it, and
it can set it's permissions back to that of the original person.
What appears to be happening here is that the MacOS X UI is adding a
set of standard elements to the menubar of an application. Those
include the Apple menu and the Services menu item. The UI presumably
handles those elements when the user selects them, the application
never sees them. In those particular cases the UI is then executing
a program. (I certainly hope it's not executing dynamically loaded
code, or this problem becomes very difficult to fix.) The standard
way of executing a program in Unix code is fork-and-exec. First you
make a copy of yourself, then you replace it with the new
application. That needs to be changed in this case to
form-setuid-and-gid-and-exec. In other words, it needs to fork, then
set itself back to the *real* user of the application, and then run
the program. I don't know whether the MacOS X apis even provide
those semantics, but if not, they will real soon.
This isn't an issue for the dock or other UI elements because they
are being run by separate processes that are not setuid. It's only
an issue for elements that are provided by the UI, and that run
separate applications automatically. (Obviously if the application
itself runs other applications, it needs to take the issue into
consideration as well--but that's the responsibility of any
application that is going to be run as root, and the application
writers should be aware of it--this however is not a problem that
application writers have any control over).
- --
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
[EMAIL PROTECTED] (or ...!alice!nazgul for time travelers :-)
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Security 7.0.3
iQA/AwUBO88CEyZsPfdw+r2CEQJeVgCeNbr4qltYcgx0mSaHm+9OrkTEBWcAnjrv
6ZGr9EPKJ+a82PmGPmNGOxQG
=iKAa
-----END PGP SIGNATURE-----
