bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH/RFC] do not source/exec scripts on noexec mount points


From: Chet Ramey
Subject: Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
Date: Wed, 16 Dec 2015 20:13:41 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]