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
next prev parent 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).