public inbox for developer@lists.illumos.org (since 2011-08)
 help / color / mirror / Atom feed
From: Lonnie Cumberland <lonnie@outstep.com>
To: developer@lists.illumos.org, udo.grabowski@kit.edu
Subject: Re: [developer] A couple of kernel questions
Date: Wed, 17 Jul 2024 16:12:12 -0400	[thread overview]
Message-ID: <e1aaa4a2-4f36-49ee-b215-ffb34ea97ef0@outstep.com> (raw)
In-Reply-To: <906458fe-725c-9fa6-bf86-8b9ca1d62933@kit.edu>

Yea, I thought about ACLs and RBAC approaches but think that a 
property-graph database could possibly offer much more potential still. 
I could, of course be wrong on this, but I think that it is a very 
interesting possibility maybe worth experimenting with and investigating 
further as a thought.

Also, I think that a hierarchal tree-based filesystem allows for too 
many attack vectors for bad actors who can gain access up and down the 
tree looking and mostly eventually finding weak spots to assault and 
gain access.  A PGDb approach seems like it would not expose neighbor 
nodes (i.e. application libraries and others) and would be perfectly 
in-line with application/data sandboxing ideas while allowing much more 
control with a finer-grained approach, just as a rough thought.

Thanks again,
Lonnie

On 7/17/2024 10:06 AM, Udo Grabowski (IMK) wrote:
> On 17/07/2024 15:28, Lonnie via illumos-developer wrote:
>> ....
>> 2. Another crazy thought that I had was about the possibly of 
>> investigating what it might take to (fork illumos for an experiment) 
>> and try to remove the dependencies on a hierarchal tree-based 
>> filesystem and to implement a type of "Property-Graph Database 
>> (PGDb)" filesystem.  The rationale here is that a hierarchal 
>> tree-based filesystem can easily be represented as well but that a 
>> PGDb filesystem also allows for assigning new types of attributes to 
>> files, blocks, objects, users, etc. and thus allowing for granular 
>> security on users at the application level.  Users can be 
>> allowed/disallowed to see/access application/files/block/objects and 
>> only authorized applications are "mapped" to a particular user.
>>
>
> That's mostly ACLs and RBAC/Projects. Already there...
>
>
> ------------------------------------------
> illumos: illumos-developer
> Permalink: 
> https://illumos.topicbox.com/groups/developer/Tf2a2de95f2063204-M80e6a50f391c7bb694aa2500
> Delivery options: 
> https://illumos.topicbox.com/groups/developer/subscription


  reply	other threads:[~2024-07-17 20:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-17 13:28 Lonnie
2024-07-17 14:06 ` [developer] " Udo Grabowski (IMK)
2024-07-17 20:12   ` Lonnie Cumberland [this message]
2024-07-17 19:06 ` John Howard
2024-07-17 20:05 ` Lonnie Cumberland
2024-07-17 20:12   ` Joshua M. Clulow
2024-07-17 20:27     ` Till Wegmüller
2024-07-17 20:09 ` Joshua M. Clulow
2024-07-17 20:22   ` Lonnie Cumberland
2024-07-17 20:47     ` John Howard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1aaa4a2-4f36-49ee-b215-ffb34ea97ef0@outstep.com \
    --to=lonnie@outstep.com \
    --cc=developer@lists.illumos.org \
    --cc=udo.grabowski@kit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).