venkat@sun.com (11/27/90)
I have a process running in the background at all times which performs certain tasks. How can my process write messages to the system console irrespective of who owns /dev/console? Any responses will be appreciated. Venkat Rao sun!iis!venkat@uunet.uu.net
buck@sct60a.sunyct.edu (Jesse R. Buckley Jr.) (11/27/90)
On Nov 26, 16:10, iis!venkat%sun.com@nisc.nyser.net wrote: } I have a process running in the background at all times which performs certain } tasks. How can my process write messages to the system console irrespective } of who owns /dev/console? Any responses will be appreciated. } }-- End of excerpt from iis!venkat%sun.com@nisc.nyser.net Simple, just make your process Set uid root. -- -Buck ! User n.: A programmer who will believe (buck@sct60a.sunyct.edu) ! anything you tell him.
dce@smsc.sony.com (David Elliott) (11/28/90)
In article <25112@adm.brl.mil> sct60a.sunyct.edu!buck@sct60a.sunyct.edu (Jesse R. Buckley Jr.) writes: > >On Nov 26, 16:10, iis!venkat%sun.com@nisc.nyser.net wrote: >} I have a process running in the background at all times which performs certain >} tasks. How can my process write messages to the system console irrespective >} of who owns /dev/console? Any responses will be appreciated. > > Simple, just make your process Set uid root. Which may or may not be simple. Even assuming that Venkat has root priveleges, changing just any old program to be setuid can have serious consequences. I recently found that a program that had been changed to setuid root for using the SVR4 real-time scheduler didn't deal with file access correctly, and could be used by anyone to overwrite any file in the system. In this case, I believe it's better to use some connection to syslog (either the syslog subroutine or the logger program), since that will allow for configuration of the messages. Programs (including parts of the kernel) should avoid writing directly to the console.
buck@sct60a.sunyct.edu (Jesse R. Buckley Jr.) (11/29/90)
On Nov 27, 16:10, David Elliott wrote: } [EDITED] } Even assuming that Venkat has root priveleges, changing just any old } program to be setuid can have serious consequences. I recently found } that a program that had been changed to setuid root for using the } SVR4 real-time scheduler didn't deal with file access correctly, and } could be used by anyone to overwrite any file in the system. } } In this case, I believe it's better to use some connection to syslog } (either the syslog subroutine or the logger program), since that will } allow for configuration of the messages. Programs (including parts } of the kernel) should avoid writing directly to the console. }-- End of excerpt from David Elliott OK OK, you got me! I hadn't thought of that, and I should have said something about security. I did assume (I know.) that it was a isolated program though. -- -Buck ! User n.: A programmer who will believe (buck@sct60a.sunyct.edu) ! anything you tell him.
limes@sun.com (Greg Limes) (11/30/90)
This may be too simple :-) Permissions are only checked during the open; so, open /dev/console once at the top. After that, it doesn't matter how the permissions change, or how the ownership changes. Now, just log in to the console (should set owner of /dev/console to you), start your program, and log out. The other alternative is to make your program Set-GROUP-Id to the group called "tty", assuming your system follows the idea of using the group-writable bit to allow messages, and keeps all terminal lines owned by group "tty". If all above fails, make the program setuid-root; open /dev/console once at the top, then do a "setuid(getuid())" to change the user-id back to the real calling user-id so the rest of the program executes with the privileges of the user. If you do this, CAREFULLY examine every line of code executed while setuid root. -- Greg Limes limes@eng.sun.com "Just One More Bug Fix ..."