cmd modifiers options: CPU affinity, ASLR, lightweight exec...
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
> Subject: command modifiers (Re: Changes with provided user's source code transform (Size and performance efficient rewriting of the `dash.test` built-in)) > Date: Thu, 1 May 2008 02:00:41 +0100 >> `expr, "$1" * "$2"` -- don't expand shell patterns; or just >> `expr:, $1 * $2 `; options may be included e.g. >>> `test,n "$file" -nt arch/avr32/*` -- don't leave unexpanded patterns >>> `test:,b $file -nt [^a].*` -- pattern is BRE, (ERE, etc, what libc provides) > (examples are using -nt proposition, but `make` with file-name patterns can > there as well) etc. (still collecting input) > >>`/bin/chroot! .`-- don't copy environment After today's exercises i'd like to add: `sed,c` -- set CPU affinity; maybe some free CPU choice is needed also: `sed,c` stick to CPU 0 `sed,c` to CPU 1, another form `sed,cpu` If one day address space randomization will be freely available, thus adding useful security feature, but adding burden of random number generation, good (i.e. slower) random number generation, obviously flexible run-time configuration of this stuff on exec time will be needed. `sed,rnd[-]` `sed,r[+]` set +r -- switch off ASLR set -r -- switch on ASLR more common extended format: set -F[r], set +F[rnd], set +F[asr] Of course if any execve() kind with this, "light-weight process" or any other performance/size options will be implemented by cool kernel kids, then shell will be ready to exploit it fully. But flexible configurability run-time or build-time seems not a key here (everywhere?). I mean it, not even going into config/build. Now i face with user interface, that is absolutely dumb and frost-bitten. One must do, type, repeat, wait for so many stupid things without a hint from UI for help (command lines, text editors, pagers, browsers)... -- sed 'sed && sh + olecom = love' << '' -o--=O`C #oo'L O <___=E M -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[LARTC] [Bugtraq] [Yosemite Forum] [Photo]