We're installing a digital media system at the college radio station I work at. We're trying to give programmers (read; DJs, not coders) access to the music, without allowing them to copy any of it to their flash drives or transfer it across the Internet.
We're running on Windows systems (Windows XP for the client machines, and Windows Server 2008 for the media server). My idea is this.
- Create a user (ProgramUser) that has no access at all to the digital media.
- Create a user (MediaUser) that has read-only access to the digital media that programmers know nothing about and do not know the password to.
- Have users log in to Windows as ProgramUser, giving them no access at all to the media.
- Run our playback application (Traktor) as the MediaUser, allowing the programmer to play back media but not copy or modify it.
This seems like the perfect solution, but there's one gotcha. If the playback application or machine crashes, the programmer is the only person who will be able to get it running again in a reasonable amount of time (we're a 15 kW FM radio station, so downtime is a big deal). Hence my dilemma...
How can I give the programmer the ability to start our playback application as a user they do not know the password to?
sudo.bat
surprisingly it won't ask password again even after reboot or power failure
Disable USB flash drives, Internet access, etc. on these machines.
There are a couple ways I can think of off hand to maybe get around this problem. First (and more difficult) would be to write a small windows service that launches Traktor. Thus, the ProgramUser can ask the service for a new Traktor instance, and the service is running as MediaUser so Traktor is launched as MediaUser.
Another possibility, and much easier, is to have a startup shortcut set up that launches Traktor on every log in - Windows shortcuts allow you to set the credentials of the appropriate user in the shortcut properties. If the computer ever crashes, the programmers just need to log in, and they have a new Traktor running as MediaUser!
Hopefully one of these solutions will work for you!
You can make a program that starts the MediaUser's process for the DJ. This can be done so that it will run as ProgramUser.
The password/credentials for MediaUser would need to be compiled into the program, so that it knew the password, but the end user would never need to be aware of this. They'd just have a button or program that says "Restart Tracktor", and it can do all of the work.
Here is a C# example of the process. The only change would be hard-coding the credentials so the DJ doesn't see them.
The ideal situation would be for you to modify Traktor to run as a service, with a separate GUI. This gives you the best security options - Traktor would then be running as the user with the correct credentials, and no one needs know what they are, or needs to type in the password to restart it. In fact, you can make it restart itself if it crashes in the services snapin.
Your GUI to drive Traktor then gets written as its own application that the user runs as herself, it sends messages to the Traktor service (via TCP/IP, RPC, shared memory, or any other form of IPC) to make it do what the user wants. If you made the GUI work using a cross-network protocol (for example, TCP/IP) then the user can log into her workstation and the traktor service can run on a more reliable server, possibly locked away to prevent "accidental" reboots. If you're good, you could write a web application to drive Traktor instead (that is, the web server would send the messages to the service) and your user could run the station from home!
The traktor service would be started with the server, without needing to be logged in.
Take a look at Steel RunAs. I've used it for several scripts in my SysAdmin career when no other alternatives were plausible. It's definitely handy. It generates an executable file, in which it encrypts stored credentials. Linkage