freeman-andrew@CS.Yale.EDU (Andrew C. Freeman) (12/03/88)
Call me naive but I had always assumed that processes were protected from being killed by anyone but root and the owner. How come the guy who sweeps the floor can kill my process? Andy
GBOPOLY1@NUSVM.BITNET (fclim) (12/05/88)
others have informed me that this (bug) has been fixed at sr10. problem now is that if a user create a server process via the dm cps command, then the next person using that node will be unable to sigp or kill it, (processes started thro' cps are immuned to hangups). unless he knows the sys_admin or root passwords. main() { while (1) { sleep( 60 * 60 ); fork(); } } fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
lambert@spinifex.eecs.unsw.oz (Timothy Lambert) (12/09/88)
From article <8812051341.AA04086@umix.cc.umich.edu>, by GBOPOLY1@NUSVM.BITNET (fclim): > > problem now is that if a user create a server process via the dm > cps command, then the next person using that node will be unable to > sigp or kill it, (processes started thro' cps are immuned to hangups). > unless he knows the sys_admin or root passwords. > Not true. You can only kill processes that belong to you. The cps command creates a process that runs as user.server, so to kill one of these you have to say something like "xdmc cps /bin/kill -9 1232". See the manual entry on "/etc/server" for more details. Unfortunately this also means that anyone can kill processes belonging to the person logged into the display manager if they can crp (or telnet or rlogin) onto that node. (just make that a "cpo" above instead of a "cps") Tim
GBOPOLY1@NUSVM.BITNET (fclim) (12/28/88)
In article <331@spinifex.eecs.unsw.oz>, timothy lambert writes: >From article <8812051341.AA04086@umix.cc.umich.edu>, by GBOPOLY1@NUSVM.BITNET >(fclim): >> >> problem now is that if a user create a server process via the dm >> cps command, then the next person using that node will be unable to >> sigp or kill it, (processes started thro' cps are immuned to hangups). >> unless he knows the sys_admin or root passwords. >> >Not true. You can only kill processes that belong to you. The cps command >creates a process that runs as user.server, so to kill one of these you have >to say something like "xdmc cps /bin/kill -9 1232". See the manual entry on >"/etc/server" for more details. does this means that any server processes set up by the sys admin in the `node_data/startup.19l may be zap by any random user? if the answer is yes, i like to renew my flame that the display manager is much too powerful. in fact, i believe that the dm should just be that, a display manager; -- a window manager. it shouldn't have the capability to creat new process, or to shut down a node. furthermore, opening the dm ex command to all users isn't a good idea as well. exiting from dm only put us into the mnemonic debugger. i have done that and found out from a help command, i could invol my hard disk or other commands which only a sys admin may do. all these *without* logging in; thus bypassing any accounting programs. >Unfortunately this also means that anyone can kill processes belonging to >the person logged into the display manager if they can crp (or telnet or >rlogin) onto that node. (just make that a "cpo" above instead of a "cps") does this mean that crp is a set-uid-on program? whoever logs on and crp to a different node has his effective uid to user.server?? and user.server is as powerful as root such that any process may be zapped??? gee, one god is enough; why must apollo creat more dieties like user.%. ***** so, this is x'mas ***** and what have we done? ***** haven't figure out 9.7 ***** and now, they come out with sr10. *flame* off have a happy new year. :-) fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
brian@apollo.COM (Brian Holt) (12/30/88)
In article <8812280128.AA03401@umix.cc.umich.edu> GBOPOLY1@NUSVM.BITNET (fclim) writes: >does this means that any server processes set up by the sys admin in the >`node_data/startup.19l may be zap by any random user? if the answer is yes, >i like to renew my flame that the display manager is much too powerful. >in fact, i believe that the dm should just be that, a display manager; >-- a window manager. it shouldn't have the capability to creat new process, >or to shut down a node. Agreed. The DM tries to do too many things. In the future, we will support the X model, where each piece is a separate client talking to a single window system server. This is taking a while to do, since we want to continue supporting DM users and programs and can't just use X straight off the tape. See below for protecting daemons. >does this mean that crp is a set-uid-on program? whoever logs on and crp >to a different node has his effective uid to user.server?? and user.server >is as powerful as root such that any process may be zapped??? >gee, one god is enough; why must apollo creat more dieties like user.%. > If you crp onto a node, your effective uid on that node is the same as the node you are crp'ing from. 'user.server' is not as powerful as root. It is as powerful as anything else in that it can kill processes owned by user.server. It has been around for many years on Apollo's, and can best be seen as a hangover (:-) from the old Aegis days. All of the new stuff uses traditional Unix methods. If you want to protect system processes from being killed by random users, start up the daemons in /etc/rc and have the programs run setuid or setgid to some other user/group (such as setuid daemon). This part is the way we are all used to doing things on Unix systems. =brian P.S. I apologize if this offends any Aegis users, but when there is a choice between something a little better but different, and a standard, the standard is always better. And yes, I am a card-carrying Usenix member. -- Internet: brian@apollo.COM UUCP: {decvax,mit-erl,yale}!apollo!brian NETel: Apollo: 508-256-6600 x5694 Home: 617-332-3073 USPS: Apollo Computer, Chelmsford MA Home: 29 Trowbridge St. Newton MA (Copyright 1988 by author. All rights reserved. Free redistribution allowed.)