How to Put a DACL on Floppy Drives


SUMMARY
=======

There is no way to put a DACL on the floppy drives or on
the COM ports with REGEDT32, or using the Control Panel or other
part of the user interface. Also, there is no way to use the
Win32 API to put a DACL on the floppy drives or on the COM ports
that survives reboots.

However, the SD_FLPPY sample does put DACLs on the floppy drives or on
the COM ports that survive logoff and logon; that is, these DACLs
are on the floppy drives or on the COM ports until the next reboot.
This sample is a good starting place for anyone writing code to apply DACLs.

A version of this sample program can be installed as a service, so
that each time the machine boots up the DACLs are automatically re-applied.

This sample is not a supported utility.

MORE INFORMATION
================

There are possibly as many desired user interfaces to this sort of
functionality as there are people thinking about this, so it is
not a purpose of this sample (or the service variation of
it) to present an incredibly cool user interface to how the
DACLs get applied. A very simplistic approach is taken to the
user interface.

To run
------

Type sd_flppy to lock the \\.\A: and \\.\B: devices.

You can optionally put SD_FLPPY.EXE in the Startup group or a logon script.

Notes
-----

The version of this program that is packaged as a service is
in this same directory and is built along with SD_FLPPY.EXE by
the same makefile.

The packaged-as-a-service approach might better suit people who
need to change the DACL on the floppy drives without requiring a
reboot or logoff. After installing the FLOPLOCK service on
the machine, the client application, CHGFLPSD can be used over the
network to lock, unlock or query the floppy-locked-state of any
machine where the FLOPLOCK service is running.

So, this packaged-as-a-service approach might better suit people
that would like to be able to inquire over the net what the
DACLs are on the floppy drives of particular machines (to check
or audit them). This approach might better suit people that
would prefer that the DACLs be applied as the system boots up so
the DACLs are applied before any user has logged on at the keyboard.

The packaged-as-a-service approach is more aligned with the notion
of protecting the floppies as a resource on a particular
_machine_ (regardless of who if anyone is logged on), whereas
the SD_FLPPY approach (running an .exe at logon time) is
more along the lines of keeping a particular user from using
the floppies on any machine that that user might use. However,
once the user has logged onto the machine and locked the
floppies with SD_FLPPY the floppies will stay locked until
reboot. Of course a utility could easily be written that could
run in the startup group of a different authorized user to force the
floppies on any machine this user logs onto to be unlocked.

As noted above, the FLOPLOCK service is built by the single
makefile in this directory. FLOPLOCK.EXE is the main element of
the packaged-as-a-service version. FLOPLOCK installs as a service, using
INSTSRV.EXE. INSTSRV.EXE, as well as CHGFLPSD.EXE, is also built by the
single makefile in this directory

Run "instsrv" to get help on the switches to use when running
INSTSRV.EXE to install the service.

FLOPLOCK creates a named pipe which CHGFLPSD opens to pass
over the lock/unlock/query operations to a particular machine
running FLOPLOCK.EXE - the named pipe is at all times protected
by an Admins-only DACL

Run "chgflpsd" to get help on the switches to use when running
CHGFLPSD.EXE.