procmod group?
procmod group?
procmod group?
procmod group?
sudo command?
sudo?
procmod?
The difference is in InjectionControl and how it
is called.
Bertran Guihéneuf's version checks whether the user is in the
procmod group, and, if not, adds (after a confirmation
dialog) the user to the procmod group. This affects
all programs run by this user, and could be a security risk.
This version, on the other hand, first checks whether
DesktopManager
is being run in the procmod group, regardless of whether
the user is a member. By setting the DesktopManager file permissions
such that DesktopManager is a member of the procmod group,
with the "set group on execution bit" set, it is no longer necessary
to add the user to the procmod group. DesktopManager is
less secure (but no less secure than Bertran Guihéneuf's)--but
we trust DesktopManager, right?--but no other programs are given
procmod abilities. Nevertheless, if there is a problem,
for example, if DesktopManager is installed on a disk which is mounted
with the nosuid flag, then the program falls back to
the behaviour of Bertran Guihéneuf's version.
mach_inject so it could run on an Intel Mac.
See some history for more details.
procmod group?First, what is a group? A group is a way of organizing users.
Every file is owned by a user and a group.
Every user is a member of at least one group. A reason to have a user
in more than one group is, for example, permissions. For example,
a user has administrative priviledges if and only if (s)he is a member
of the admin group. So, because
/Applications is owned by the admin group
(and the root user) with group write permissions allowed,
therefore any user with administrative priviledges can drag applications
into (or out of) the Applications directory to (un)install programs.
On an Intel Mac,
the procmod group is used to identify those users that
are allowed to inject code into running processes. By default,
only the root user is a member of the procmod
group.
procmod group?
niutil -readprop / /groups/procmod users
procmod group?
sudo niutil -appendprop / /groups/procmod users user
where user is the username of the user you wish to add.
procmod group?
sudo niutil -destroyval / /groups/procmod users user
where user is the username of the user you wish to delete.
sudo command?sudo (superuser-do)
allows you to execute a command as root.
By default, you must have administrative
priviledges to use sudo and you must enter your password
for it to work. Subsequent sudo commands executed within
five minutes of the last one will not require reauthentication, however.
sudo?Because sudo works in a Terminal, you do not need
to be logged in as an administrator to use it. You simply need to be
logged into a Terminal as an administrator to use it. I know two
ways of doing this.
If you open a Terminal and type "login",
then you will be prompted for a username and password. Use an
administrator username and password; from then until you type
"logout" or "exit", everything you type in that
Terminal will be as if you were using a Terminal logged in as that
administrator. However, if you do this in an xterm, you may have problems
with Display authentication (i.e. launching GUI apps as the administrator).
Alternatively, you can type "su admin" where
admin is the username of the administrator. You will then
be prompted for the administrator's password. From then on, until you
type "logout" or "exit", everything you type in that
Terminal will mostly be as if you were using a Terminal logged in as that
administrator. However, various environment variables--including
$DISPLAY if you are using an xterm--will be those of
the original nonadministrative user. This can be annoying--for example,
the directory does not change to the administrator's home directory, and
the path is not customized to the administrator's
preference--but this means that X continues to function.
procmod group, with the
setgid
bit set, does seem
to work, regardless of who owns the file.
Hopefully nothing different from other versions.
PPC Macs can use the old mach_inject
code which does not need to run with procmod group
permissions. So InjectionControl should do nothing.
procmod group, whereas PPCs don't even have a
procmod group.) Although the files are identical, the
installer automatically sets permissions in a specific way. So the
"distribution" installer checks whether you have an Intel Mac or not,
and then runs the appropriate "package" installer. Unfortunately, this
roughly doubles the size of the installer, but fortunately does not
increase the size of the installation itself.
I am assuming you have an Intel Mac. If you have a PPC, then I am baffled, because this should not have happened. There are several possibilities for the Intel Mac:
/Applications folder (if not, replace
/Applications with the installation folder), type,
in a terminal,
ls -al /Applications/DesktopManager.app/Contents/MacOS/DesktopManager
You should see something like
-rwxr-sr-x 1 user procmod 208516 Jul 23 23:39 /Applications/DesktopManager.app/Contents/MacOS/DesktopManager
where user is likely, but need not be, your username.
chmod 2755 /Applications/DesktopManager.app/Contents/MacOS/DesktopManager
If you get a "permission denied" type of error message, then
repeat that command, but preceded with "sudo ".
If you still get an error message, and your account does not
have administrator permission, then type
"su admin" where admin is an
administrator account name on your computer, and then try
sudo chmod 2755 /Applications/DesktopManager.app/Contents/MacOS/DesktopManager
again.
procmod", then, in
a Terminal, in an account with administrator priviledges (use
the su command as in the previous point, if not)
type
sudo chgrp procmod /Applications/DesktopManager.app/Contents/MacOS/DesktopManager
chmod 2755 sets the "set group on execution" bit
for the DesktopManager executible. However, this has no effect
on a disk that is mounted with the nosuid flag. To
check if this is stymying you, type, in a Terminal,
mount. You will see a bunch of lines that look
something like
something on /something/else (flags)
For example, the first line of the output from mount
on my computer reads
/dev/disk0s2 on / (local, journaled)
which says that /dev/disk0s2,
also known as the second partition on my primary harddrive,
is mounted on '/', and that it is 'local' and 'journaled'.
I have no lines whose '/something/else' is
'/Applications', and so this is the line relevant for
my installation of DesktopManager. Since
'nosuid' is
not one of the listed flags, I do not have this problem. If you
see 'nosuid'
in the list of flags, then you have four
options:
nosuid flag.
Since I know nothing about your system,
I refuse to provide instructions on how to do this.
You probably shouldn't.
procmod
group. Then DesktopManager will run properly.
procmod?procmod group
is the option, in DesktopManager's Window Inspector,
to put a window on all workspaces.
YMMV.
This FAQ was created 2006-08-13 09:12 PDT, using FAQ2html.
-
This page was last modified 2006-08-13 09:12 PDT.
©2006 jeremy.smallinfinity.net. The program and its source code has various additional (open source) copyrights associated with it, as detailed in the source code.