Re: justifying --context=CTX (-Z) for upstream coreutils, like mkdir

[James Antill <james.antill@redhat.com>]

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

On Tue, 2006-08-22 at 19:16 +0200, Jim Meyering wrote:

> >> I think there's a deeper difference in our understanding of how
> >> this hypothetical fscon program would work.  I expect that fscon
> >> would call some new function to request that a specified fscreate
> >> context be applied (as the default) to the next exec call.
> >> When I first read the descriptions of setexeccon and setfscreatecon,
> >> I thought the latter would do just what I wanted.  Unfortunately,
> >> its semantics aren't analogous to those of setexeccon.
> >
> > setexeccon sets the context for the next execution, not the context for
> > the next execution of the next execution, these are not in any way
> > comparable.
> 
> Sorry, I can't parse that.
> I'll rephrase the part I understand:
>   setexeccon sets the execution context for the next execve call
> 
> I would like fscon to set the default fscreate context to take effect
> for the next execve call -- then it performs that execve call.

 I think their argument is, that atm. you have:

        setexeccon
        [...stuff which isn't exec...]
        exec <-- affects this.
        
        setfscreatecon
        [...stuff which isn't open(O_CREAT)...]
        open(O_CREAT) <-- affects this.
        
...and you want:

        setfspostexeccon
        [...stuff which isn't exec...]
        exec
        [...stuff which isn't open(O_CREAT)...]
        open(O_CREAT) <-- affects this.


> It's more of the one task, one tool Unix approach to problem solving.

 Personally I don't believe this has been the case for decades, but
anyway...

> Another program that works this way: setarch.

 It doesn't work that way, setarch calls the personality() syscall. This
is basically a global variable inside the kernel. For instance:

% cat ~/personality.c
#include <sys/personality.h>

int main(void)
{
        personality(-1);
        return 0;
}
% gcc -Wall -W -o ~/personality ~/personality.c
% strace -e trace=personality setarch i386 ~/personality
personality(PER_LINUX32)                = 0
personality(0xffffffff /* PER_??? */)   = 8
Process 9009 detached
% strace -e trace=personality setarch i386 sh -c ~/personality
personality(PER_LINUX32)                = 0
personality(0xffffffff /* PER_??? */)   = 8
Process 9013 detached

> Both were mentioned in my earlier posts.
> 
> In principle, what I'm suggesting is no more unusual than what the
> setarch program does nor what the setexeccon function does.
[...]
> The patch program (which I also mentioned) is a better example.

 As someone else said, I think people want -Z (and/or matchpathcon) on
commands that have -m and preservation on commands that have
owner/mode/etc. preservation. Patch doesn't do either of those.
 mknod/mkfifo/mkdir do have -m, so it seems natural to have -Z (and
setting umask before could have worked, but having -m options was deemed
to be better).

 You would never want -Z in tar to do what you said, AFAICS.

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]