[PLUG] Clarifying -- Re: Permissions for an entire PARTITION

[Larry Brigman]

The reason you can do some of this with USB and optical is that these are
devices that don't show up until they are inserted and are handled with
hot-plug/udev settings.
People have specific use cases that lots of people want.  It gets written
and refined by the community.

It's possible to do what you want but you will need to write a wrapper
script around mount where it does the mount of the device gets the metadata
that you want from the partition
and then decide what options that you really wanted to mount the device
like.

Until you have the script and the metadata file format, you will be editing
udev rules to achive what you want.

On Thu, Nov 10, 2016 at 6:09 AM, Richard Owlett <rowlett at cloud85.net> wrote:

> On 11/9/2016 6:13 PM, Tom wrote:
> > 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
>
> I've come close for the case of a USB flash drive - facilitate by
> Debian's treatment of removable devices.
> I should be able to come closer with socalled rewritable optical
> media, but I don't have appropriate facilities.
>
> Hints of my mindset ate in
> https://lists.debian.org/debian-user/2016/11/msg00361.html FWIW ;/
> Thank you.
>
>
>
> > * 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
> >> PLUG at lists.pdxlinux.org
> >> http://lists.pdxlinux.org/mailman/listinfo/plug
> > _______________________________________________
> > PLUG mailing list
> > PLUG at lists.pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> >
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>