On 25 August 2012 15:06, Matt Rice <[email protected]> wrote: > On 8/23/12, Jiří Zárevúcky <[email protected]> wrote: >> [...] >> >> The filenames themselves are local to the namespace, and there are in >> fact no global names for any file. I.e. communicating a filename to a >> task running with different namespace (and by extension, different >> permissions) is pointless, as it's relative to something the task >> doesn't have access to at all. Doesn't that solve the problems you are >> referring to? > > not exactly, one thing still of concern is the opposite, e.g. > accepting a local filename from a task running in a different namespace, > couple this with giving a local filename to a task running in a > different namespace and you have a directory server, but the directory > server is not reflected in the security model. > so looking at the namespaces themselves won't show that one task has > access, but it does. > > the theory is that the filenames themselves are divisible from the > file, and can be given without just giving the file itself via the > model absent the mechanism that is also external to verify > permissions. thus in the capability model, a capability is an atomic > unit there is nothing to split the name from the capability, you just > give them the file. > > names then are kept closely guarded e.g. the shell/user interaction > deal has them, and it does the lookup, and passes files directly. the > tasks themselves just work with e.g. file descriptors and don't need a > namespace. >
Sorry, but reading this, I have absolutely no idea what is your interpretation of my concept, what is a different concept from related theory and what is the actual problem. It would be helpful if you could rephrase it using a pattern like "You propose that ....", "<some theory> deal with this like .....", "The problem is that when you try to do <something>, what happens is <something>"; I'm unable to infer such context from your formulations. >>> Capability >>> systems in general tend to do away with filesystems all together, as >>> much discussed in many threads e.g. 'Explicit Persistence Considered >>> Harmful'[3], but it would be good to consider how your VFS reacts to >>> the confused deputy problem in particular when a program serves 2 >>> masters. >>> >> >> What exactly do you mean by "serving two masters"? > > i'll try and use the terms from your concept document and apply them > to the confused deputy problem, but what I mean is > > lets say a user has a source/build namespace, and the compiler in > addition to the source/build namespace has an extra billing namespace > that the user does not have access to. thus the users permissions are > only a subset of the compilers permissions, thus the concern here is > of keeping the 2 sets of permissions separate instead of running the > compiler with the union of permissions from both sets. so by 'serving > two masters' I mean, running with multiple sets of permissions and > avoiding mixing of them (in ways which was not intended.) > My idea is that no task started by the user can access something the user doesn't have access to. Or more generally, task's permissions is always a (possibly proper) subset of the parent's permissions. As far as user shell is concerned, there are two classes of programs. Commands, which share the namespace with parent shell, and applications, which each have an exact configuration of their namespace, not unlike per-application fstab. There's no mixing of permissions anywhere. If an application needs superior permissions, it simply needs a server part, which of course needs to be properly configured from an administrative shell or some similar environment. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
