From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: viewprinting: what format should views be stored in? Date: Thu, 19 Aug 2004 23:13:25 -0700 Message-ID: <41259685.9090205@namesys.com> References: <20040819074027.8429715D94@mail03.powweb.com> <41248D43.3040905@dgreaves.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <41248D43.3040905@dgreaves.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: David Greaves Cc: David Dabbs , George Beshers , reiserfs-list@namesys.com David Greaves wrote: > Hi > > I've been following and have an interest - I hope my comments and > observations are valuable. > > First, allow me to suggest some more terminology - like George, I > always like to see this done early :) > Masklet : set of modifications to a filename's access authorisations > Mask: collection of Masklets (possibly only 1) > > Most of the time one will use 'mask'; eg one can now traverse a mask > (cf an image overlay) however one can use masklet to refer to a > specific instance (a complex mask pixel) > I've used this terminology below and I think it's OK. > > David Dabbs wrote: > >> Fall-Through Point >> The point during some file operation at which it is determined that >> the file is not filtered by the mask. The request [for operation X on >> the file] >> is passed on to the VFS/underlying filesystem. >> > This doesn't sound right. > (Basically I suspect there has been confusion over 'visibilty' and > file attribute masking) > > When did masks specify visibility of files? According to Hans : > >> Hmm. Yes, views should allow masking permissions. > > > mind you, he then said: > >> We need to be able to support specifying a mask that allows any file >> within a given directory to be visible. That is, we need to support >> dirname/* but we don't yet need to support dirname/foo.* > > > I think (see last paragraphs of this email) that we have a collection > of masklet types. > >> >> >> Features & Constraints >> ---------------------------------------------------------------------- >> Masks - must support dirname/* - do not [yet] need to support >> dirname/foo.* >> - should not allow symbolic link traversal unless the file pointed to >> is within the mask. >> >> > simple question here: > does dirname/* go deep into the directory tree?? Yes, it does. > > It doesn't in shell syntax > > Maybe dirname/** > (which means the complete tree below dirname) > > Important I think. > Also introduces the question of 'rule' interaction > > dirname/bar/foo : maska > dirname/bar/* : maskb > dirname** : mask c > > which mask? > options: > AND? > most specific? (definition) > first to match? Not sure I understand the question, but I'll guess. The answer is that masks are anded, and have an order. > > >> Masked Processes >> - May not create hard links. >> - Child processes [of a masked process] must inherit the parent's >> "mask bit" and mask definition. >> >> > remind me - what is the mask tied to? UID/GID, EUID, PID, PGID? > filesystem? process running. > Hans actually says it's derived from the executable. > What if it changes between two processes starting? then it changes for both processes. > Does the running processes mask change? (cf chmod a file - seems > reasonable but...) > I'd think it needs to be pretty atomic... > In fact, maybe changing masks on a running (mounted?) system is a > potential security hole and forbidden? > I think I could think of race examples. > > aside: talking about reuse, maybe the recent lkml JOB patch is useful: > http://marc.theaimsgroup.com/?l=linux-kernel&m=109278360210574&w=2 > > + A job is a group of related processes all descended from a > + point of entry process and identified by a unique job > + identifier (jid). A job can contain multiple process > + groups or sessions, and all processes in one of these sub- > + groups can only be contained within a single job. > + > + The primary purpose for having jobs is to provide job > + based resource limits. Ok with me. I leave it to George. > > Maybe exe's can have something _like_ setuid? setmid()? > mid being based on jid? ? > >> Questions >> ---------------------------------------------------------------------- >> >> >>> All file types and access methods will be supported, yes? (mmap, >>> AIO, DIRECT, pipes, hard/sym links, etc.) >>> >>> Hans: Yes. >>> ...except that they cannot create hard links (above) >>> >> >> >> Is this restriction unequivocal (yes)? Any other forbidden Unix fs >> objects or fs operations? >> >> > Obviously creating a hardlink _can_ circumvent semantically specified > security. > But shouldn't that just be a masklet attribute? see below (end) > >>> Early on in the conversation, there was discussion about >>> "permissible functionality." At a minimum, a mask, true to its name, >>> will effect filesystem object _visibility_. It was not completely >>> clear whether the mask will be proscriptive viz operations. IOW, >>> will the mask say that fooprocess "is not permitted to [attempt to] >>> RWX object bar?" I believe this is not something masks will do, but >>> I wanted clarification. >>> >>> >>> I don't know why I don't understand your question, but I don't.....;-) >>> >> >> >> >> Let me try again. At a mininmum, a mask specifies what objects are >> visible to a process, correct? If objext X is included in or not >> explicitly excluded from the mask, then fooprocess is allowed to >> _attempt_to_ operate on object X. I say "attempt to" because, at that >> point (fall-through), the mask is finished wrt the operation, yes? >> Permission to actually carry out an operation on object X is >> determined by the user/object/permission mapping in the underlying >> filesystem. >> >> What was not clear to me was whether masks specified, proscribed, or >> in any way controlled filesystem operations (permissions) for objects >> that are visible when running under the mask. If so, what can be >> specified and is it an "allow" a "deny" or either? >> >> > So, you're saying that a mask can deny authorisation but not grant it. Yes. > (In which case 'mask' is a good word and the concept of AND goes into > the foundations) > > A process can read/write/execute according to FS permissions. > If the files 'acl/attr' doesn't allow writing then the mask _cannot_ > override this and allow a masked process to write to the file. > > This sounds sensible. > >>> Hans, in your preferred approach you referred to "a format that is >>> as if it is a subdirectory of the masked executable." Did you have >>> in mind checking for something like /usr/bin/fooprocess/metas/mask >>> when exec() loads the exe, >>> >>> yes >>> >>> and if this exists then the files rooted in this directory would be >>> set as the process's root filesystem? >>> >>> Your statement is imprecise. The mask will be checked first, and >>> then iff it falls through we do a normal filesystem traversal. >>> >> >> >> It was imprecise because perhaps I had a different vprint concept and >> implementation in mind. Using the creation tool, JAdmin creates a >> mask for fooprocess. The mask would be a directory structure rooted >> at /bin/fooprocess/metas/mask. All files (not dirs) in this tree >> would be hard links to the "real" files specified in the mask. > No, I don't like this. >> Only dirs & files included in the spec are visible. When an instance >> of fooprocess is started, /bin/fooprocess/metas/mask is automagically >> mounted as the process's root filesystem. The mask would be the >> filesystem. Other than the use of the metas reiserism (and mask >> maintenance wizardry) >> this is not any different than chroot. Since the end result here is >> to be no more secure than chroot, but very much easier to deploy and >> maintain, is there a reason why this cannot be the case? >> >> > I think the 'thing' at /usr/bin/fooprocess/metas/mask > is a semantic expansion of the mask (ie it's like a directory tree but > it doesn't point to files, it just contains lots of masklets). > It can be traversed in parallel to the real tree traversal and the > masklets it returns will modify the real results. It is purely > semantic. I've expanded this later. > > Call it a maskfs? > The email subject becomes: > Re: viewprinting: what format should maskfs use? > The answer of course is something very similar to reiserfs. > > (BTW perhaps, eventually, /proc//maskfs is a better place - and > the mask checking moves to vfs - all of a sudden it's not reiser > specific - although maskfs is reiserfs code) > >>> If you are limited to the semantic layer, then there's no stat node >>> with which to play tricks. >>> I wonder if it would be feasible if masks only specified exclusions? >>> If, for instance, the mask wanted to exclude /foo/*, then the >>> directory foo would exist (in the mask semantic tree). To exclude >>> /etc/passwd, passwd would exist in the directory /etc. Since you're >>> already going to need to preempt dcache searches (aren't you?) >>> >>> Sigh, yes, or we need to use dcache for the mask. >>> >>> you can insert a search of the mask tree. If the search fails, then >>> it is not excluded and the request falls through to normal VFS >>> handling. In the /etc/passwd case above, it would find /etc/passwd >>> and so the file is excluded. Processing would stop there, returning >>> some error. How does this sound? >>> I don't quite understand this paragraph above. >>> >> >> Probably because I'm not on the same page as you and George. >> Imagine a filesystem with two trees: one, the real >> root filesystem and two, the anti-root tree (exclusions). This >> fs would be the root fs for the process. Let's say fooprocess has the >> following exclusions: >> >> /etc/passwd >> /etc/shadow >> /var >> >> Above, when I said "insert a search of the mask tree" what I meant was >> "first search the exception [semantic] tree (anti-tree) associated >> with this process. If you find the object there, then report it as >> NOT FOUND. >> Otherwise, proceed with a normal fs tree search (fall-through). > I suppose it could work. Ok. Phase II. Should go into final report for Phase I. >> > > Here's how I see parallel traversal and using masklets could work > (purely semantic) > I don't know if this is feasible as I don't know if you could > intertwine the fs/maskfs traversals. > > The mask just contains: /etc/config.file > > 1. open (/etc/passwd) > search the maskfs for the first traversal point / : default - fall > through to fs > search the fs for / - normal behaviour > search the maskfs for the traversal point etc/ : default - fall > through to fs > search the fs for etc/ - normal behaviour > search the maskfs for the object passwd : not there -> file not found No, / is not a fall through point, only /etc/config.file is. There is no need to see if the underlying fs allows something if the mask does not. The mask is fully traversed, and only if we hit a fall through point do we go to the underlying fs, and if we go to the underlying fs, we only come up to the mask again for symlinks. > > 2. open(/etc/config.file) > search the maskfs for the first traversal point / : default - fall > through to fs > search the fs for / - normal behaviour > search the maskfs for the traversal point etc/ : default - fall > through to fs > search the fs for etc/ - normal behaviour > search the maskfs for the object config.file : read only - fall > through to fs _with masklet_ > search the fs for object - apply masklet and return. > > Note that in specifying /etc/config.file you infer a mask on / & /etc/ > so maybe directorys mentioned in passing such as /etc/config.file imply > / : x only > /etc : x only > /etc/config.file : masklet > > of course this needs to be aligned with the comment at the start > > This mask is interesting: > /etc : doesn't exist > /etc/config.file : r only > >>> George: >>> To give a couple of examples: >>> 1) A given process (say a restricted shell) can not exec() an >>> executable with the set-uid bit on. >>> - directly >>> - indirectly (e.g., via bash) >>> 2) Apache can only create/write files in /var/web/incoming. >>> - files created or modified can not have any execute bit set >>> and executing chmod is excluded. >>> >>> Hans: >>> this protection happens while traversing the mask or at the fall >>> through point. >>> > Don't you always fall through - but sometimes you 'hit' a masklet and > sometimes you 'miss' > >>> Hmmm, we need to accumulate a set of permissions that apply to >>> something that are specific to how we got there. >>> > In fs traversal the permision at a point in traversal (ie a directory > on the way) doesn't affect the permission of the object when the fs > has been traversed except insofar as it may not be reachable. So why > do you need to do this? > (I agree you need to check each traversal point against the mask) > > As I said above: This mask is interesting: > /etc : doesn't exist > /etc/config.file : r only > > it will report file not found due to a traversal failure - isn't that > what you'd want? > >>> That could be complex in the VFS details. We can defer it to Phase >>> II if necessary. George, you should spend a day (not this week) >>> figuring out how much work it would be to make that work. It will >>> be the details of it that will be dangerous.... >>> >> >> >> I'll tackle scenario #2: >> * Executing chmod would be excluded because it would not be visible >> in the mask. >> * "files created or modified can not have any execute bit set" >> Implicit in this statement is that, in addition to filtering object >> visibility, masks will preempt/proscribe certain fs operations -- in >> this case, the setting of certain attributes (i.e. exec bit). If >> this is correct >> then what can masks allow/prohibit WRT operations/attributes performed >> on objects. This is what I was trying to clarify with my earlier >> question. >> >> >> > If you have a maskfs then if you traverse it for a filename and get a > hit then the results of the hit are the masklet to be applied. > > If you get a miss then implicit exclude states: > * doesn't exist (shortcut the call - file not found) > > If it hits, what types are there in a masklet? > I think: > * doesn't exist (file not found) > * file attribute mask (eg: prevent any writing) > * acl 'mask' (an obvious extension of attr but no longer simple 'AND' > logic) > * syscall mask (prevent hardlink and maybe chmod - although see below) > * 'umask' (chmod) mask (prevent setting suid or execute bit - but may > allows setting +w and setgid on directories - may extend to acls too) > > David > >