cc: Subject: Re: Re: sh.1, nval.3, shell.3 + shcomp + suid_exec ... / was: Re:[ksh93-integration-discuss] Re: unreferenced filesexception_listwas Re: [osol-code]Roundtwo:((pre-)pre-review)ksh93-integrationwebrev2007-02-02 --------
> >If the exec command supports #!, and #! also works for scripts > >that are setuid and/or execute only, then there is no need for > >suid_exec. > > It works for set-uid scripts; it does not work for execute > only scripts (except those which are setuid, I think) > > >For execute only scripts, the exec call needs to open the > >file and pass down the open file descriptor as /dev/fd/n > >where n is the file descriptor. > > This we'd need to fix, perhaps. I don't see any sane reason > for execute only scripts to normally work. Why should shell scripts be different than C programs. You don't need read permission to execute a C program so you shouldn't need it to execute a shell script. > > (This is compounded by the fact that the kernel may not be able > to determine how to open execute only scripts; but a set-uid root > helper program would get into trouble even more quickly as it is > certain to fail over NFS) At the kernel level, shouldn't it can bypass ordinary file file permissions or temporarily do a setuid root to open the file. > > Could ksh93 use /proc/self/path/$(basename $0) in error messages > rather than /dev/fd/X? The shell tried to change $0 when it encounters /dev/fd/X but the method depends on the system. The link to /proc/self/exe gives the pathname for the interpreter, not the script. It would be nice of for ps, #! displayed the name of the script rather than the name of the interpreter. > > Casper > _______________________________________________ > ksh93-integration-discuss mailing list > ksh93-integration-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss > David Korn dgk at research.att.com
