-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Please see and comment on https://bugs.php.net/68526
In this proposal, this is an optional feature:
-
- new build option: --with-fpm-acl
=> no change for standard build
-
- new config options: listen.users and listen.groups
=> no change for existing configuration
ACL are set when listen.users or listen.groups are configured,
else chown to listen.owner / listen.group is still used.
Notice: chown only work when running as root (standard config), while
ACL are also available for standard users.
Comment / feedback are very welcome.
This seems to be a small self contained feature.
I'd like to be able to implement this in 5.6+
Is a RFC needed ?
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlR62NgACgkQYUppBSnxahgKUQCfUr1k6Zg2t9whhgVJbWKWU6Gd
OdAAoJ1TlJ9Z9Rgcg3vfy4Q9rKWsrfXk
=TJRJ
-----END PGP SIGNATURE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi,
Please see and comment on https://bugs.php.net/68526
In this proposal, this is an optional feature:
- new build option: --with-fpm-acl
=> no change for standard build
- new config options: listen.users and listen.groups
=> no change for existing configuration
ACL are set when listen.users or listen.groups are configured,
else chown to listen.owner / listen.group is still used.
Nit-picking, but I always find it awkward when two variable names differ only by an "s" - too easy to mistake one for the other, misread (or miswrite) documentation, etc. So perhaps listen.acl_users and listen.acl_groups?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/11/2014 10:35, Rowan Collins a écrit :
Nit-picking, but I always find it awkward when two variable names
differ only by an "s" - too easy to mistake one for the other,
misread (or miswrite) documentation, etc. So perhaps
listen.acl_users and listen.acl_groups?
Make sense, patch updated to use listen_acl_*
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlR66jAACgkQYUppBSnxahj7zwCeMDVfuGvr/9YSYjaZBCbRgEDK
VwAAoK8+qdGhJ0xhPtehh/JstnVoW3gQ
=fiL0
-----END PGP SIGNATURE
This seems to be a small self contained feature.
I'd like to be able to implement this in 5.6+Is a RFC needed ?
Is it possible for the ACL header to be in another location? That's
the only potential issue I can see with the patch itself.
However, I think we should stop including features in our patch
releases. I've heard a few others express similar sentiment, but it
may have been more targeted at what we are allowing for "bug fixes" in
patch releases. Anyway, that's my input.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/11/2014 16:34, Levi Morrison a écrit :
This seems to be a small self contained feature. I'd like to be
able to implement this in 5.6+Is a RFC needed ?
Is it possible for the ACL header to be in another location?
Patch refreshed with a check for this header.
That's the only potential issue I can see with the patch itself.
However, I think we should stop including features in our patch
releases. I've heard a few others express similar sentiment, but
it may have been more targeted at what we are allowing for "bug
fixes" in patch releases. Anyway, that's my input.
Yes, I'm one wanting to reduce new feature in stable branch...
This is the reason why I propose this feature for 5.6 (not 5.5) and
with a new option to not change default build.
And I also think use of ACL can slightly improve security.
But of course, there is always some risk.
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlR7XJMACgkQYUppBSnxahg2XACfVqwVDnme0KT6Ct1Ev4Uu0Kvd
2TIAoKbG8oUzUzBSGWsDJDVLF9PHBAP5
=TKIl
-----END PGP SIGNATURE
However, I think we should stop including features in our patch
releases. I've heard a few others express similar sentiment, but
it may have been more targeted at what we are allowing for "bug
fixes" in patch releases. Anyway, that's my input.
Yes, I'm one wanting to reduce new feature in stable branch...This is the reason why I propose this feature for 5.6 (not 5.5) and
with a new option to not change default build.
But that's still technically introducing a feature in a patch release.
From a documentation point of view, it's a lot tidier if we only ever
have to say "since PHP x.y" rather than "since x.y.z", and as you say,
there's always a risk. I don't know much about this case, but let's say
a mistake allowed a misconfigured build to apply an inadvertently wide
ACL; having that emerge in a patch release could mean downstream
maintainers losing faith in the official releases, and make everyone's
lives harder.
Part of the stated aim of the release process RFC [1] was to "reduce the
time to get new features in a release", and the solution to that was to
guarantee a release every year, so that there's never more than a few
months to wait, while simultaneously having clean, safe, patch builds.
The crucial paragraph is this:
No feature addition after final x.y.0 release (or x.0.0). Self
contained features or new SAPIs could be carefully considered on a case
by case basis.
That wording implies - in my opinion - that the burden of argument
should be on the feature's sponsor for why an exception should be made,
but there's a temptation to shoot for inclusion everywhere and see if
the RM challenges it.
[1] https://wiki.php.net/rfc/releaseprocess
--
Rowan Collins
[IMSoP]
On Sun, Nov 30, 2014 at 8:09 PM, Rowan Collins rowan.collins@gmail.com
wrote:
However, I think we should stop including features in our patch
releases. I've heard a few others express similar sentiment, but
it may have been more targeted at what we are allowing for "bug
fixes" in patch releases. Anyway, that's my input.Yes, I'm one wanting to reduce new feature in stable branch...
This is the reason why I propose this feature for 5.6 (not 5.5) and
with a new option to not change default build.But that's still technically introducing a feature in a patch release.
From a documentation point of view, it's a lot tidier if we only ever have
to say "since PHP x.y" rather than "since x.y.z", and as you say, there's
always a risk. I don't know much about this case, but let's say a mistake
allowed a misconfigured build to apply an inadvertently wide ACL; having
that emerge in a patch release could mean downstream maintainers losing
faith in the official releases, and make everyone's lives harder.Part of the stated aim of the release process RFC [1] was to "reduce the
time to get new features in a release", and the solution to that was to
guarantee a release every year, so that there's never more than a few
months to wait, while simultaneously having clean, safe, patch builds. The
crucial paragraph is this:No feature addition after final x.y.0 release (or x.0.0). Self contained
features or new SAPIs could be carefully considered on a case by case basis.That wording implies - in my opinion - that the burden of argument should
be on the feature's sponsor for why an exception should be made, but
there's a temptation to shoot for inclusion everywhere and see if the RM
challenges it.
this is also my interpretation(that is should be of a case-by-case approval
process instead of a RMs can veto if they really want), but I seem to be
the minority on this side.
having said that, I would be fine having this one in 5.6.x.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Sun, Nov 30, 2014 at 8:09 PM, Rowan Collins rowan.collins@gmail.com
wrote:However, I think we should stop including features in our patch
releases. I've heard a few others express similar sentiment, but
it may have been more targeted at what we are allowing for "bug
fixes" in patch releases. Anyway, that's my input.Yes, I'm one wanting to reduce new feature in stable branch...
This is the reason why I propose this feature for 5.6 (not 5.5) and
with a new option to not change default build.But that's still technically introducing a feature in a patch release.
From a documentation point of view, it's a lot tidier if we only ever have
to say "since PHP x.y" rather than "since x.y.z", and as you say, there's
always a risk. I don't know much about this case, but let's say a mistake
allowed a misconfigured build to apply an inadvertently wide ACL; having
that emerge in a patch release could mean downstream maintainers losing
faith in the official releases, and make everyone's lives harder.Part of the stated aim of the release process RFC [1] was to "reduce the
time to get new features in a release", and the solution to that was to
guarantee a release every year, so that there's never more than a few
months to wait, while simultaneously having clean, safe, patch builds. The
crucial paragraph is this:No feature addition after final x.y.0 release (or x.0.0). Self contained
features or new SAPIs could be carefully considered on a case by case basis.That wording implies - in my opinion - that the burden of argument should
be on the feature's sponsor for why an exception should be made, but
there's a temptation to shoot for inclusion everywhere and see if the RM
challenges it.this is also my interpretation(that is should be of a case-by-case approval
process instead of a RMs can veto if they really want), but I seem to be
the minority on this side.
having said that, I would be fine having this one in 5.6.x.
For me, this feature is self contained, and even benefit from an
activation switch (--with-fpm-acl) , saying it will not change the
codebase if not activated. So it may be included in 5.6
However, I agree that it's bad to have : "from 5.6.Z , you may use
FooBar feature", better to have "from 5.6".
Having patches introducing new features in revision versions is hard
to remember and bad for versionning
Julien.P