Locking the sound device?
Vick Khera
khera at thneed.cs.duke.edu
Tue Dec 4 03:35:24 AEST 1990
In article <4442 at idunno.Princeton.EDU> subbarao at phoenix.Princeton.EDU (Kartik Subbarao) writes:
In article <1990Dec2.163300.11093 at Neon.Stanford.EDU> frankjr at neon.stanford.edu writes:
>
>When I am using a sun sparcstation 1 from the console, is there any way to
>prevent another user from telneting to my machine, and playing sounds on it?
Sure - from audio(4) :
`` The audio device is treated as an exclusive resource: only
one process may typically open the device at a time. How-
ever, two processes may simultaneously access the device if
one opens it read-only and the other opens it write-only. ''
So either write a program that does open("/dev/audio", O_RDWR), or just
have a process running in the background like "cat > /dev/audio &".
That'll silence your SPARCstation.
what i'm pushing for is for Sun to change ownership of /dev/audio from
the login program like they do for /dev/console and /dev/fb. if you
have sources, it should not be too difficult to add a change of
ownership for /dev/audio where /dev/fb is changed, but you will have
to have a sysadmin do this.
>The other questions is this. Is there a way to prevent a user from telneting
>on to the machine while I am using it, and do an xloadimage on my display?
Weeeeeeeeeeeelllllll, you could be REALLY nasty and open all the pty's to
prevent any more logins, but even then someone could rsh into your machine
and wreck havoc. There is really no way from stopping someone running
processes on your machine if you're not priviledged.
you don't necessarily want to stop them from running processes on your
machine, as it may be a server for something or they might need access
to some file on that machine.
>Lastly, there is a program called decay which effectively makes the image on
>your screen "melt", the other program I have seen is one that a little person
>comes on the screen in the lower left corner, and pushes your screen off the
>side of your monitor. Is there any way to prevent these from working if the
>user invoking them is not on the console.
Oh yes, don't I know them well :-). Nope - there's really no way currently
to "protect" your sun in this fashion. Maybe there will be sometime later,
but I doubt it.. Besides, its too much fun ;-).
BZZZZT. there exists right now a way to prevent other people from
connecting to your X server using the authorization scheme provided
with MIT's release of X11R4. i use it daily, and i don't use xdm.
output from running xhost prints just the following line:
access control enabled (only the following hosts are allowed)
which means that even people locally logged in cannot connect to my X
server and diddle with my screen (or watch me type in that all too
important root password.) there are some people here that do
"xhost +" so that anyone on the internet can diddle with their screen,
and some who judiciously use xhost to control access. of course, most
of them end up with main compute servers having access, so anyone on
those machines can play with their X displays.
follow up to comp.windows.x
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vick Khera, Gradual Student/Systems Guy Department of Computer Science
ARPA: khera at cs.duke.edu Duke University
UUCP: ...!mcnc!duke!khera Durham, NC 27706 (919) 660-6528
More information about the Comp.unix.questions
mailing list