You don't need to jail postfix for your situation. Build Mutt with smtp
support, and set smtp_server to localhost. Your SMTP processes will run
in the global context, and mutt will only need a socket to that.
* On 11 May 2014, Shawn Zaidermann wrote:
> I understand. There is definitely always t
Hi,
On Sun, May 11, 2014 at 12:20:27PM -0700, Shawn Zaidermann wrote:
> I understand. There is definitely always that possibility that users will
> get a shell. However, can SELinux help in this case? Perhaps I can confined
> the users with basic access, one that does not allow a user to run any
>
I understand. There is definitely always that possibility that users
will get a shell. However, can SELinux help in this case? Perhaps I can
confined the users with basic access, one that does not allow a user to
run any execution from their home or /tmp. We have a debian deployment
but can mig
On Fri, May 09, 2014 at 03:14:03PM -0700, Shawn Zaidermann wrote:
> Is there a way to completely disable the shell-escape feature?
In short, no. If you're trying to prevent mutt users from gaining any
access to the shell, you also have to concern yourself with things
like:
my_var=`run arbitrar
On 09.05.14 09:55, David Champion wrote:
> You can unbind the key (or bind it to no-op), but the user can still
> rebind it unless you also remove the enter-command binding (preventing
> them from entering a bind command). Also ensure that they cannot source
> any muttrc files (check bindings for
* On 09 May 2014, Shawn Zaidermann wrote:
> Is there a way to completely disable the shell-escape feature?
You can unbind the key (or bind it to no-op), but the user can still
rebind it unless you also remove the enter-command binding (preventing
them from entering a bind command). Also ensure t
Is there a way to completely disable the shell-escape feature?