Re: [PATCH 0/2] Add SystemD's sandboxing options

[Andrew Latham]

Willy

I was about to suggest the comments in file. You get to keep the great
ideas but enable simple defaults for all.

On Tue, Feb 27, 2018 at 11:33 AM, Willy Tarreau  wrote:

> On Tue, Feb 27, 2018 at 05:52:22PM +0100, Vincent Bernat wrote:
> > >> Tim Duesterhus (2):
> > >>   MINOR: systemd: Add SystemD's Protect*= options to the unit file
> > >>   MINOR: systemd: Add SystemD's SystemCallFilter option to the unit
> file
> > >
> > > I took a look, but my systemd incompetence limited my ability to
> understand
> > > what this really does. How does systemd act to do this exactly ? I'm
> very
> > > worried that the only way it could proceed would be by running the
> process
> > > under ptrace causing a tremendous slowdown, and additionally making the
> > > process unobservable/undebuggable. Do you know how it proceeds
> > > internally ?
> >
> > It uses seccomp.
>
> Ah OK, so we can expect more or less the same level of slowdown as the
> meltdown workarounds approximately. Not huge but not negligible either.
>
> I tend to agree with Pavlos that such config options should not be placed
> by default. They will definitely break some setups in an unusual way. For
> example, those using external checks will see their external commands fail
> (or randomly fail, which is worse). Regarding the access restriction on
> /home and /root, it turns out that I've met at least one of each in field
> (the config files and binaries were placed there). Also it would seem quite
> plausible that some maps or ACLs could be loaded from such locations. In
> fact, since by default haproxy is supposed to chroot to an empty directory
> and drop privileges to an unused user, the remaining possibilities for an
> attacker are much narrower than what can be achieved by only restricting
> certain classes of syscalls.
>
> I think it could make sense to add such lines as a comment to the existing
> files so that they serve as illustration of what can be done for users who
> want to go further. Or maybe this is already well-known from systemd users,
> I don't know.
>
> Cheers,
> Willy
>
>


-- 
- Andrew "lathama" Latham -

Re: gitignore in tarballs

[Andrew Latham]

Willy

No problem. I will clone and get you a patch. I found this by complete
accident so no worries.

On Tue, Oct 7, 2014 at 7:18 AM, Willy Tarreau w...@1wt.eu wrote:
 Hi Andrew,

 On Mon, Oct 06, 2014 at 03:39:41PM -0500, Andrew Latham wrote:
 I waited about a month. Here is a pull request and you can see the
 diff also https://github.com/haproxy/haproxy/pull/3

 OK, I didn't notice that haproxy-* would automatically ignore doc/haproxy-*
 simply because there are currently such files and they're already tracked!

 Could you please send your patch here, it's really too much painful to try
 to get it from github, I had to give up after 10 minutes not finding any
 way to retrieve it :-(

 Either you use the classical git format-patch or if you feel brave enough
 you can just use git send-email :-)

 Thanks,
 Willy




-- 
~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~

Re: gitignore in tarballs

[Andrew Latham]

Willy

Diff attached. Happy to help if there are any issues.

On Tue, Oct 7, 2014 at 7:22 AM, Andrew Latham lath...@gmail.com wrote:
 Willy

 No problem. I will clone and get you a patch. I found this by complete
 accident so no worries.

 On Tue, Oct 7, 2014 at 7:18 AM, Willy Tarreau w...@1wt.eu wrote:
 Hi Andrew,

 On Mon, Oct 06, 2014 at 03:39:41PM -0500, Andrew Latham wrote:
 I waited about a month. Here is a pull request and you can see the
 diff also https://github.com/haproxy/haproxy/pull/3

 OK, I didn't notice that haproxy-* would automatically ignore doc/haproxy-*
 simply because there are currently such files and they're already tracked!

 Could you please send your patch here, it's really too much painful to try
 to get it from github, I had to give up after 10 minutes not finding any
 way to retrieve it :-(

 Either you use the classical git format-patch or if you feel brave enough
 you can just use git send-email :-)

 Thanks,
 Willy




 --
 ~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~



-- 
~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~
diff --git a/.gitignore b/.gitignore
index ec1545a..762f5ad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ src/*.o
 *.log*
 *.trace*
 haproxy-*
+!doc/haproxy-*.txt
 !src/*.c
 make-*
 dlmalloc.c

Re: gitignore in tarballs

[Andrew Latham]

Willy

Thanks, was in a hurry, every project is a little different in
process. Attached.

On Tue, Oct 7, 2014 at 7:44 AM, Willy Tarreau w...@1wt.eu wrote:
 On Tue, Oct 07, 2014 at 07:28:55AM -0500, Andrew Latham wrote:
 Willy

 Diff attached. Happy to help if there are any issues.

 Andrew, if I asked for the format-patch output, it's because it
 provides your commit message, your authorship etc...

 You just have to do this :

git format-patch -1 $COMMIT

 with the commit ID in $COMMIT, or simply git format-patch -1 if
 the commit is the last one.

 Then it gives you a file named 0001-your-subject.patch that you
 can simply send and that I'll apply using git am. It's also
 very convenient for reviewers since they can make comments inline
 about some specific parts of code.

 Also, keep in mind that having a patch ready for merging is the
 best way to ensure it will get quickly accepted. On the opposite,
 expecting any upstream maintainer to write the commit message
 themselves for something they did not write is the best way to
 ensure the patch will stay there forever.

 Last, please take a look at section 5 of the README (how to
 contribute), it explains how to write a relevant subject that I
 will not have to edit when merging it. That's equally a key to
 having your patches quickly merged.

 Do not hesitate to ask for any help, it's very important for me
 that contributors feel at ease with submitting changes. Don't be
 afraid of doing mistakes, we all do.

 Thanks,
 Willy




-- 
~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~
From 927c07583d55c3033eb76cee54c8c246d51736e4 Mon Sep 17 00:00:00 2001
From: Andrew Latham lath...@gmail.com
Date: Tue, 7 Oct 2014 07:45:54 -0500
Subject: [PATCH] DOC: Address issue where documentation is excluded due to a
 gitignore rule.

---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index ec1545a..762f5ad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ src/*.o
 *.log*
 *.trace*
 haproxy-*
+!doc/haproxy-*.txt
 !src/*.c
 make-*
 dlmalloc.c
-- 
2.1.1

Re: gitignore in tarballs

[Andrew Latham]

Thanks, Now I know how to send you good high quality code.

BTW, Thanks for HAProxy, it rocks.

On Tue, Oct 7, 2014 at 8:07 AM, Willy Tarreau w...@1wt.eu wrote:
 Hi Andrew,

 On Tue, Oct 07, 2014 at 07:51:12AM -0500, Andrew Latham wrote:
 Willy

 Thanks, was in a hurry, every project is a little different in
 process.

 Yes I know :-)

 Attached.

 Applied to both 1.6 and 1.5. Thank you very much!
 Willy




-- 
~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~

Re: gitignore in tarballs

[Andrew Latham]

I waited about a month. Here is a pull request and you can see the
diff also https://github.com/haproxy/haproxy/pull/3

On Fri, Aug 29, 2014 at 9:30 AM, Andrew Latham lath...@gmail.com wrote:
 For a change in internal SCM I attempted to move the haproxy code over
 for our continuous integration system and found that the .gitignore in
 the tarball was blocking some documentation files and one example.
 Can this file be excluded from the tarballs? The gitignore rules could
 be updated/cleaned to resolve this issue.

 --
 ~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~



-- 
~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~

gitignore in tarballs

[Andrew Latham]

For a change in internal SCM I attempted to move the haproxy code over
for our continuous integration system and found that the .gitignore in
the tarball was blocking some documentation files and one example.
Can this file be excluded from the tarballs? The gitignore rules could
be updated/cleaned to resolve this issue.

-- 
~ Andrew lathama Latham lath...@lathama.com http://lathama.net ~