On 12/15/15 4:53 AM, konsolebox wrote:
> Ok I accept your point. So it's actually about `source` and `bash
> file`, correct? So would this mean every script I `source` would need
> +x bit now? And if it's not about the +x bit and only about `noexec`,
> would stuff I place that I would want to not execute (with execve(),
> etc.) in a `noexec` directory no longer be `source`-able, even though
> I'm still wanting those to be `source`-d? `source` is meant to only
> require readable permission.
Correct. If this were to be in effect, anything that you wanted to
source would fail if the file to be read were on a file system mounted
noexec.
> You complicate it. I'm both a user and an administrator to my
> personal system and I don't want that function running by default in
> my bash. Simple.
This raises the queation of the set of systems to which this is intended
to apply. It's clearly inappropriate for general-purpose Unix/Linux
systems, but single-purpose systems on which the user does not have
access to the file system or the shell are a different story.
> The thing is, you're trying to implement the concept of `noexec` in
> the application level. You're making use of `noexec` as a flag to
> make bash restrict itself from `source`-ing scripts located on a mount
> point or directory with such attribute. `noexec` (and the kernel that
> implements `noexec`) really has nothing to do with it. You're just
> trying to -extend- the scope of `noexec` to applications. That is the
> inconsistency which is clear. You're just wanting bash to behave
> based on its concept, and not really based on a rule of a system or a
> particular system feature.
This is true. The question is whether or not your mental model of how
`noexec' should work includes this case. It's clearly true that the
proposal embeds policy in the bash binary. Whether or not that policy
is appropriate depends on your answer to the previous question.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
