I am afraid that what you want to do cannot be done: * access control at physical partition/disk level cannot be done. Maybe in newest NTFS versions, but that is not a Linux realm * you could control access to disk at BIOS boot time by setting HDD password, though I suspect that it is not quite what you want.
You can control access via: * user/groups at mount point for physical partitions/drives * encryption keys at block level on mount time - this can be done for partitions as well as storage containers (encrypted file containig file system such as home dir) * user/groups and/or netgroups at access level to a networked storage such as SMB/CIFS or NFS+Kerberos Alternatively you could use Virtual Machines to achieve the disk/partition isolation. Please feel free to correct me, if I forgot/omitted some new/old way of controlling block access storage. Good luck, Tomas On Wed, 2016-11-09 at 09:48 -0600, Richard Owlett wrote: > On 11/7/2016 6:20 AM, Richard Owlett wrote: > > > > My primary use case is a laptop: > > 1. purchased explicitly for use as a test bed. > > 2. whose HD has been erased multiple times in ONE day. > > 3. is isolated from ANY network. > > 4. has multiple installs of Debian, primarily classed as: > > a. a full GUI install - what one would get choosing all > > installer defaults. > > b. a GUI install limited to the tools I use routinely. > > c. an install oriented to whatever my current experiment > > needs. > > 5. has 2 classes of "DATA Partitions": > > a. those which UID 1000 may mount without entering any > > password. > > b. those which *ANY* user may mount only by using root > > password. > > [deleting paragraph which "muddied" the waters ;] > > Consider a machine with a single hard drive with vast unused > space on it. > I wish to create two classes of partitions: > One class would require root privileges &/or appropriate > fstab entry to mount. > [i.e. current default behavior] > A new "thingy" [explicitly avoiding calling it a partition ;] > > This "thingy" would have metadata within itself identifying who: > 1. may *NOT* mount it at all. > 2. mount it *READ ONLY* > 3. may mount it read/write with access determined by > individual file permissions. > > I'm beginning to suspect a variation of LVM might be relevant. > Haven't found appropriate docs yet. > > I'm doing some experiments with USB flash drives that show > potential for illustrating effects I desire. They are *EXPLICITLY > UNSUITABLE* for my application as they are removable devices! > > Any clearer than my first try? > > > > > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
