It seems with the right vfs design you could create a command like “shadow make install” and it create a view of the file system and allow changes but those changes are stored in the shadow but not written to the actual vfs. This would allow you to do that very kind of inspection. I’ve done something like this at the application level using Python so that I could run unit tests without actually changing the file system.
On Wed, Apr 7, 2021 at 9:14 AM William ML Leslie < [email protected]> wrote: > On Wed, 7 Apr 2021 at 22:51, Andrew Warkentin <[email protected]> > wrote: > > > > > > On 4/7/21, William ML Leslie <[email protected]> wrote: > > > > On Wed, 7 Apr 2021 at 22:13, William ML Leslie > > > > > > > > Oh, I should probably clarify with an example: when porting setuid > > > > binaries, the common practice (at least to a first order) is to have > > > > the "normal" filesystem be the default root filesystem of the exec > > > > server, but to also gain a capability to the caller's filesystem to > > > > use for resolving user-provided filenames. It's not ideal, and yet > > > > already a huge step forward over the unix permissions model. > > > > > > > That's a little bit like the path-capability mechanism I'm planning to > > > implement, although the path-capability API will only provide paths > > > for informational purposes such as displaying in a GUI. Also, UX/RT > > > won't have any client-visible concept of a "capability to a > > > filesystem" (that's way too coarse-grained for my liking; security > > > boundaries usually don't correspond to disk partitions or network > > > shares, and having to set up some kind of filter filesystem for every > > > directory/file you want to control access to is cumbersome). However > > > it will be possible to give a process access to all files in a > > > directory (mount point or otherwise) through either its permission > > > list or through a path capability. > > > > There's nothing to say that a filesystem is a disk partition or such; > > in CapROS at least you could be handed access to a Directory which is > > a map to as few or as many capabilities as you like, which may or may > > not be references to Files or Directories. I have heard stories that > > KeyKOS has access to a unix-style filesystem, but in all the > > descendants I have access to, directories were just normal > > orthogonally-persistent objects that allowed you to ask for a > > capability by name and any other resemblance to the unix filesystem is > > probably accidental. > > > > The reason I find forwarding a reference to a filesystem an > > interesting concept is that you may want some applications interaction > > with the system state to be transactional. My favourite example is > > the installer. More and more installers think that it's acceptable to > > call sudo on your behalf (it's really not; I'm looking at you, nix and > > waterfox) but even if you use the standard gnu build system `$ > > ./configure ; $ make ; # make install` there's often no easy way to > > tell how it might clobber the system on `make install`. Running the > > installer itself within a transaction and allowing the user to inspect > > the changes is a great usability improvement, and the way to force the > > installer to submit to the transaction is to only allow it access to > > resources that are transaction aware (such as an overlay filesystem). > > > > I'm aware that if you don't have any need to support legacy you can > > often avoid the need for such things, but that's a rare place to be > > in, considering we're talking about full-cream desktop operating > > systems. > > > > -- > > William Leslie > > > > Q: What is your boss's password? > > A: "Authentication", clearly > > > > Notice: > > Likely much of this email is, by the nature of copyright, covered > > under copyright law. You absolutely MAY reproduce any part of it in > > accordance with the copyright law of the nation you are reading this > > in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without > > prior contractual agreement. > > _______________________________________________ > > Devel mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- Royce Mitchell, IT Consultant ITAS Solutions [email protected] There are three hard problems in computer science: naming things, and off-by-one errors. _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
