Stephen Hahn wrote:
Please read
http://blogs.sun.com/sch/entry/verexec_1_a_simple_execute
for some background, and then review
http://cr.opensolaris.org/~sch/on-verexec/
I'm debating implementing some of the refinements mentioned in the
blog entry, as well as providing manual pages for both verexec(1) and
isaexec(1).
The concept is very much needed. I like the environment variable
override and particularly the per command override.
So now we potentially have three wrapper scripts around a given program:
1) Select the version
2) Select the "best optimised version" (not just 32 vs 64)
3) Run with different creds (pfexec)
So how do we start /usr/bin/foo if all three are needed ?
pfexec verexec isaexec /usr/bin/foo
pfexec isaexec verexec /usr/bin/foo
isaexec pfexec verexec /usr/bin/foo
isaexec verexec pfexec /usr/bin/foo
verexec isaexec pfexec /usr/bin/foo
verexec pfexec isaexec /usr/bin/foo
Note the order really does matter, particularly for pfexec since it
needs to lookup the exec_attr(4) database. Currently that is done by
pfexec itself but in the near future (PSARC 2009/377) the lookup will be
done by the kernel but /usr/bin/pfexec will still exist.
does $VEREXEC_ALTDIR have to be fully populated with everything from
/etc/verexec.d ? Or do we search $VEREXEC_ALTDIR first then search
/etc/verexec.d ? Is it worth $VEREXEC_ALTDIR being a list (':' separated) ?
Just like I really don't like the libc.so.1 lofs mount I don't like the
idea of using an lofs mount here either. However I don't think it is
needed here if the issue of isaexec/verexec/pfexec all being separate is
addressed. Especially since pfexec is already moving kernel side, hint
have a chat with Casper Dik about 2009/377.
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
