Re: viewprinting: what format should views be stored in?

[George Beshers <gbeshers@comcast.net>]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]


First, rereading my e-mails I realize that there was some thinking 
behind my questions
which was only partially articulated.  Going back to my earlier position 
which I will restate
here as:

    /Use of a mask should never corrupt the semantics defined by the
    Single Unix
    Specification /*or*/ its practical derivations and extensions, e.g.,
    BSD and Linux./

That is,/ ideally/ if I created a standalone system that "looked" like 
the system the mask
provides then the process would behave equivalently.  I emphasize 
ideally because to
actually make that the case would require something closer to a virtual 
machine---which
is clearly beyond the scope of this project.

So I am looking for potential semantic anomalies which could be 
introduced by a
mask over a reiser4 file system, i.e., border cases where some upfront 
awareness
and attention may save re-design and re-writing later on.


Hans Reiser wrote:

>
>> The issue is how the mask might change the semantics of 
>> sys_execve().  I have spent some time
>> starting to trace code around, but more work is required.
>>
>> For the moment I think we are safe if the setuid and setgroup can not 
>> be altered by the mask.
>
>
> Ok.


For the moment I will focus on how the uid (and assume the group id will 
be similar)
of a process and how the mask might lead to a different uid than would 
be expected
under standard semantics.

So we agree that the process has an associated user: actually there is 
the concept
of real and effective uid also.

I believe the statement above to be true if the process never makes a 
setuid() system's call of
one flavor or another because the uid is inherited from the process 
calling execev() or is determined
by the owner of the executable if the executable's file set-uid 
permission bit is turned on via chmod.

>>
>> We only change the semantics if the real/effective uid or gid is 
>> different at some point in the
>> processes execution because of the mask---begging situations where a 
>> call to setuid happens
>> only if a certain file is not available.
>
>
> Say more.

If the process has the code like

    if (stat("/etc/foobar.conf", statbuf)  < 0) {
         if (setuid(3) < 0) {   /* Try to become sys */
        }
        /* Do something here */
    }

And the mask hides "/etc/foobar.conf" then in fact the uid
will change but *not unexpectedly*, IMO.  The mask is
creating a changed environment but the behavior is
understandable from the source code.

Put this another way, the semantics still seem correct to me
because you are getting the behavior of "/etc/foobar.conf" actually
not being there.

Now that I think about it masking a named pipe or a lock file
is perhaps more likely to cause problems then the setuid bit.
More cogitation required...  :-)



[-- Attachment #2: Type: text/html, Size: 3669 bytes --]