achoi@cory.Berkeley.EDU (CHOI ANDREW MAN-TAT) (09/14/90)
Hello world. This is my first posting to this newsgroup, please
accept my apology in advance if I have inadvertently violated any
netiquette.
I have the following 2 questions about command 'ps' and 'wall':
1) How does 'ps' work? Where does it get the information about all
the processes running on the system? I suspect it may have
something to do with /dev/kmem (Kernel Memory); however, since
I don't have read/write permission on /dev/kmem, how can
'ps' acquire the permission to read /dev/kmem? Is there a
setuid program exec by 'ps' to get root access?
2) Even after I do 'mesg n' or 'chmod og-rx /dev/tty?', other
users can still send me message through command 'wall',
how come? Is there anyway to prevent 'wall' from sending the
message?
Thank you very much for your time and effort in answering these
questions.
Name: Andrew Choi Internet Address: achoi@cory.berkeley.edu
Phone: (415)848-5658 Address: 2605 Durant Ave., Berkeley, CA 94704
#include <std/disclaimer.h>gwyn@smoke.BRL.MIL (Doug Gwyn) (09/14/90)
In article <27773@pasteur.Berkeley.EDU> achoi@cory.Berkeley.EDU (CHOI ANDREW MAN-TAT) writes: >1) How does 'ps' work? Where does it get the information about all > the processes running on the system? I suspect it may have > something to do with /dev/kmem (Kernel Memory); Yes, the information about process state is typically obtained by directly rummaging around in the kernel's process tables. > however, since > I don't have read/write permission on /dev/kmem, how can > 'ps' acquire the permission to read /dev/kmem? Is there a > setuid program exec by 'ps' to get root access? "ps" should be installed set-GID and belong to a group such as "memory" that has read permission on /dev/kmem. >2) Even after I do 'mesg n' or 'chmod og-rx /dev/tty?', other > users can still send me message through command 'wall', > how come? Is there anyway to prevent 'wall' from sending the > message? Any version of "wall" that writes on terminals that have had "mesg n" executed on them is BROKEN. You can fix that by removing /bin/wall.
cpcahil@virtech.uucp (Conor P. Cahill) (09/14/90)
In article <27773@pasteur.Berkeley.EDU> achoi@cory.Berkeley.EDU (CHOI ANDREW MAN-TAT) writes: > >1) How does 'ps' work? Where does it get the information about all > the processes running on the system? I suspect it may have It uses "/unix" (or whatever the kernel is named on your system) to get the addresses of where the data is. Then it reads /dev/kmem (using the addresses gotten from /unix) to get the data. Throw in /dev, and /etc/passwd and there you go (i.e. ps then has all the information it needs). > I don't have read/write permission on /dev/kmem, how can > 'ps' acquire the permission to read /dev/kmem? Is there a > setuid program exec by 'ps' to get root access? Do an ls -l of /bin/ps. It should be setuid or setgid (probably setgid). >2) Even after I do 'mesg n' or 'chmod og-rx /dev/tty?', other > users can still send me message through command 'wall', > how come? Is there anyway to prevent 'wall' from sending the > message? Maybe they are running as super-user? Then they will have access to the port no matter what you set the mode to. Wall is only supposed to be used for important system messages (like "system is going down in 10 seconds") so you shouldn't be getting to many of them. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/14/90)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > Any version of "wall" that writes on terminals that have had "mesg n" > executed on them is BROKEN. You can fix that by removing /bin/wall. I disagree. When you're shutting the system down, it's definitely a good idea to let the other people on it know at least a few minutes in advance about the shutdown. If they have write perms turned off and /bin/wall won't tell them about it, how do you notify them? Phone each of them individually? Manually echo(1) a message to their terminal? If /bin/wall is sending messages to depermitted terminals when the user isn't the superuser, that's different. But just like with write(1), the superuser should be able to send messages even to users who have done a "mesg n". Better yet, since the ordinary user has little or no use for wall(1), just move /bin/wall to /etc/wall and permit it 700. -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
anagram@desire.wright.edu ((For Mongo)) (09/15/90)
In article <13850@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>2) Even after I do 'mesg n' or 'chmod og-rx /dev/tty?', other >> users can still send me message through command 'wall', >> how come? Is there anyway to prevent 'wall' from sending the >> message? > > Any version of "wall" that writes on terminals that have had "mesg n" > executed on them is BROKEN. You can fix that by removing /bin/wall. Ummm.... Isn't wall only usable by people with system access priviledges, which will just ignore the mesg? And, it would be difficult for him to fix it, because I am guessing (from his previous question) that he is not a SysAdmin.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/15/90)
In article <27XgP3w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >> Any version of "wall" that writes on terminals that have had "mesg n" >> executed on them is BROKEN. You can fix that by removing /bin/wall. >I disagree. When you're shutting the system down, it's definitely a >good idea to let the other people on it know at least a few minutes in >advance about the shutdown. If they have write perms turned off and >/bin/wall won't tell them about it, how do you notify them? You're making the standard mistake that causes many applications to be less useful than they ought to be -- you're assuming a specific usage model rather than allowing for the unlimited flexibility that UNIX caters to. Specifically, you assume that there is a person looking at data that is sent to every tty special device. In many environments, that is far from correct. For example, in mine there are printers attached to some ttys, with generic output blocked deliberately to prevent messing up what they are in the process of printing, and other ttys are being used for binary communication between cooperating processes (one on the host and one in the terminal). Generic write access is turned off on such ttys for a REASON, and it is utterly inappropriate for some unrelated application to presume that it knows best and override the write block. If a tty being used in accordance with your model has write access denied deliberately by the person using the terminal, that is because that person has decided, for whatever reason, that he does not want to receive output from foreign sources for the interim. Who are you to ignore his wishes? Maybe it is important for him to hear about impending system shutdown, etc. or maybe it isn't -- however, he has assumed the responsibility for not receiving "wall" messages and it is not proper for "wall" to second-guess his intentions. >But just like with write(1), the superuser should be able to send messages >even to users who have done a "mesg n". I also disagree with the assumption that it is proper to log in as root merely in order to exploit UNIX's intentional access permissions loophole. But in any case, neither "write" nor "wall" should communicate with "terminals" that have deliberately had external access denied for them. What is really needed is proper session and terminal management, but lacking those we should at least honor deliberate user decisions.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/15/90)
By far the simplest solution to the wall ``problem'' is to have a file, /etc/itmp, listing only interactive sessions. Interactive isn't a well-defined concept: it's defined by the way people and programs use it. write, wall, talk, and other communication programs will never touch a session unless it's interactive. People won't set up program-controlled sessions as interactive. Everyone will be happy. Of course, as many of you know, I think /etc/utmp serves the function of /etc/itmp quite admirably. write, wall, and talk are already set up to interpret /etc/utmp in this way; all we have to do is realize that the convention has been established. In article <13859@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > Specifically, you assume that there is a person looking at data that > is sent to every tty special device. In many environments, that is far > from correct. For example, in mine there are printers attached to some > ttys, with generic output blocked deliberately to prevent messing up what > they are in the process of printing, and other ttys are being used for > binary communication between cooperating processes (one on the host and > one in the terminal). Such ttys wouldn't be listed as interactive. Problem solved. ---Dan
cpcahil@virtech.uucp (Conor P. Cahill) (09/15/90)
In article <13859@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >You're making the standard mistake that causes many applications to be >less useful than they ought to be -- you're assuming a specific usage >model rather than allowing for the unlimited flexibility that UNIX caters >to. Specifically, you assume that there is a person looking at data that >is sent to every tty special device. In many environments, that is far >from correct. For example, in mine there are printers attached to some >ttys, with generic output blocked deliberately to prevent messing up what >they are in the process of printing, and other ttys are being used for >binary communication between cooperating processes (one on the host and >one in the terminal). Generic write access is turned off on such ttys >for a REASON, and it is utterly inappropriate for some unrelated >application to presume that it knows best and override the write block. > Doesn't wall(1) just send messages to terminals that users are logged into? Then there shouldn't be a problem with printer or other comm ports where user's are not logged in. To handle the case where a comm program is initiated once the connection is established, the comm program should be able to handle (and ignore) the noise generated by the message. If that is not feasible, perhaps a solution where the process turns off the "owner-write" permission bits (this is not what mesg -n does) on a tty and write is modified to not send a message to this port. I don't think this is necessary. >Maybe it is important for him to hear about impending system shutdown, etc. >or maybe it isn't -- however, he has assumed the responsibility for not >receiving "wall" messages and it is not proper for "wall" to second-guess >his intentions. If you want to allow this, I thing there needs to be two levels of mesg. The first level for turning off other user messages (like talk or write) and the second for turning off system level messages. Most people who use mesg think that they are just turning off the capability for other (non-system) people to send messages/initiate communications. >What is really needed is proper session and terminal management, but >lacking those we should at least honor deliberate user decisions. Agreed on the first part. As to the second, there needs to be some clarification of exactly what the deliberate user decision is. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
jeff@onion.pdx.com (Jeff Beadles) (09/16/90)
In <13850@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: ... >Any version of "wall" that writes on terminals that have had "mesg n" >executed on them is BROKEN. You can fix that by removing /bin/wall. ... Unless wall is being run by root... -Jeff -- Jeff Beadles jeff@onion.pdx.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/16/90)
In article <13958:Sep1510:27:5790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Such ttys wouldn't be listed as interactive. Problem solved. The problem is NOT solved until "mesg" and "write" recognize the same conventions.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/16/90)
In article <1990Sep15.132001.28596@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
-Doesn't wall(1) just send messages to terminals that users are logged
-into? Then there shouldn't be a problem with printer or other comm
-ports where user's are not logged in.
I didn't say that the printer hadn't been logged in. Users with hardcopy
terminals (e.g. letter-quaility) have used them for printing nroff output
for quite a long time now. A side effect of a reasonable nroff with
output sent to such a printing terminal is that the equivalent of "mesg n"
is performed to block "write" and "wall" during printing.
-To handle the case where a comm program is initiated once the connection
-is established, the comm program should be able to handle (and ignore)
-the noise generated by the message. If that is not feasible, perhaps
-a solution where the process turns off the "owner-write" permission
-bits (this is not what mesg -n does) on a tty and write is modified to
-not send a message to this port. I don't think this is necessary.
You're getting too elaborate. All that is necessary is for "mesg" and
"write"/"wall" to cooperate.jak@sactoh0.SAC.CA.US (Jay A. Konigsberg) (09/16/90)
In article <13850@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >Any version of "wall" that writes on terminals that have had "mesg n" >executed on them is BROKEN. You can fix that by removing /bin/wall. Or its root doing the `wall`. -- ------------------------------------------------------------- Jay @ SAC-UNIX, Sacramento, Ca. UUCP=...pacbell!sactoh0!jak If something is worth doing, its worth doing correctly.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/16/90)
In article <13870@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <13958:Sep1510:27:5790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Such ttys wouldn't be listed as interactive. Problem solved. > The problem is NOT solved until "mesg" and "write" recognize the same > conventions. write already does, just like talk. mesg does not need to recognize the same conventions, because (as other people have pointed out) its function is only to change the other-user write/talk access on an interactive tty. If the session is not interactive, mesg is senseless: it communicates information to programs that aren't paying attention in the first place. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/16/90)
In article <13871@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > I didn't say that the printer hadn't been logged in. Users with hardcopy > terminals (e.g. letter-quaility) have used them for printing nroff output > for quite a long time now. A side effect of a reasonable nroff with > output sent to such a printing terminal is that the equivalent of "mesg n" > is performed to block "write" and "wall" during printing. Is this your argument that ``mesg'' really means to change a session from interactive to noninteractive? I see it as evidence that your model is flawed. The printer really serves two entirely different purposes. The first is as an interactive session with a user. The second is as a printer to produce noninteractive output pages. Obviously both uses are multiplexed through the same physical port, say /dev/printer. The first use is handled by a pseudo-tty session, which is marked as interactive by being listed in /etc/utmp. The second use is handled by straight output to /dev/printer. The only problem is that interactive output (like wall's messages) must not be allowed to mess up noninteractive output. So whenever the printer is under the second use, the interactive session must be temporarily disconnected. As soon as it finishes, the session is reconnected, and control reverts to the first use. See? mesg/write/wall/talk/itmp (utmp) fits quite naturally into this structure. > All that is necessary is for "mesg" and > "write"/"wall" to cooperate. They already do. ---Dan
josef@nixpbe.UUCP (Moellers) (09/17/90)
In <27773@pasteur.Berkeley.EDU> achoi@cory.Berkeley.EDU (CHOI ANDREW MAN-TAT) writes: >Hello world. This is my first posting to this newsgroup, please >accept my apology in advance if I have inadvertently violated any >netiquette. >I have the following 2 questions about command 'ps' and 'wall': >1) How does 'ps' work? Where does it get the information about all > the processes running on the system? I suspect it may have > something to do with /dev/kmem (Kernel Memory); however, since > I don't have read/write permission on /dev/kmem, how can > 'ps' acquire the permission to read /dev/kmem? Is there a > setuid program exec by 'ps' to get root access? It depends very much on your system: - the "classical" way is to give "ps" setuid root an have it access /dev/kmem, as You suspect. - on more "secure" systems, or distributed systems where there are more than one "kernel memories", there usually is some kind of server or a special system call to get process information. >2) Even after I do 'mesg n' or 'chmod og-rx /dev/tty?', other > users can still send me message through command 'wall', > how come? Is there anyway to prevent 'wall' from sending the > message? Hmm, maybe "wall" is setuid root? After all, "wall" sould only be used to alert users e.g. when the system goes down (if there is any time left B-{) >Thank you very much for your time and effort in answering these >questions. Much obliged, sir! -- | Josef Moellers | c/o Nixdorf Computer AG | | USA: mollers.pad@nixdorf.com | Abt. PXD-S14 | | !USA: mollers.pad@nixdorf.de | Heinz-Nixdorf-Ring | | Phone: (+49) 5251 104662 | D-4790 Paderborn |
craig@veritas.uucp (Craig Harmer) (09/26/90)
In article <27773@pasteur.Berkeley.EDU> achoi@cory.Berkeley.EDU (CHOI ANDREW MAN-TAT) writes: ... > >I have the following 2 questions about command 'ps' and 'wall': > >1) How does 'ps' work? Where does it get the information about all > the processes running on the system? I suspect it may have > something to do with /dev/kmem (Kernel Memory); however, since > I don't have read/write permission on /dev/kmem, how can > 'ps' acquire the permission to read /dev/kmem? Is there a > setuid program exec by 'ps' to get root access? yes, i reads /dev/kmem (kernel memory) to get the information. ps is generally setuid root, or (more intelligently) setgid sys (or whatever is relevant to your machine). when ps is executed, it runs with an "effective" group id of (see the setuid(2) man page). >2) Even after I do 'mesg n' or 'chmod og-rx /dev/tty?', other > users can still send me message through command 'wall', > how come? Is there anyway to prevent 'wall' from sending the > message? root can always write to your terminal; one of the priviledges of being root is having write permission on all files (including special files, like /dev/tty). "mesg n" or "chmod 0600 /dev/tty??" should prevent other people from writing to your tty. -- {apple,pyramid,amdahl}!veritas!craig craig@hoser.veritas.com (415) 626-6827 (h) (408) 433-5588 x220 (w) [views expressed above shouldn't be taken as Veritas' views, or your views or even as my views]