On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote:
> On Fri, Apr 11, 2014 at 11:31 AM, Ron <[email protected]> wrote:
> > On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote:
> >> Ok. Am I correct in understanding that the actual system cgi script is
> >> not provided by global but it is to be created by the user or system
> >> administrator.
> >
> > Global creates everything that is needed, but installing it to the system
> > requires privilege that an ordinary user should not have. Which means
> > we need a secure and sensible interface for someone with that privilege
> > to exercise it, in a way that meets the normal distro expectations and
> > standards.
> >
> > A generated script that the user is required to run as root, or making
> > a privileged system directory 777 writable is not such an interface.
> >
> > If people want to do that on their own systems that is fine, but the
> > distro packages should never be recommending or requiring this.
> >
> >> I am looking to see if there's an obvious way to package this.
> >
> > There is a mechanism for doing this in the existing package. If something
> > equivalent to that was integrated upstream, none of this would be a problem
> > anymore.
>
> The parameters that htconfig/htmake rely on are not part of upstream
> htags. So they are broken with recent releases.
Which is why I say "something equivalent". This was the best that Shigio
and I could come up with together 15 years ago, to meet the needs of doing
this in a way that was suitable for the distro. I'd like to think that if
anything there would be Better ways to do this today, given the number of
web-appy type things that also exist.
> >> I might resort to turning this feature off in the first update and then
> >> add it to the package as I understand better what is needed on the
> >> packaging side.
> >
> > NACK. Saying "I don't need this, so I'm just going to remove it for
> > everyone else to rush out the bits that _I_ want" is not an acceptable
> > solution. If that's all you want then you can make your own local
> > packages easily enough.
>
> Turning off a feature is not my preferred option either. I am the one
> who's initiated this discussion with the intent of trying to
> understand the functionality and how to package it.
Well, your first reply to my query was "I don't use this, so I could
just turn it off". And you were still suggesting that as an option.
The equation is pretty simple really - either we solve the problem(s)
that makes this unsuitable for release with the distro, or it remains
unsuitable for release with the distro.
> > I am very interested in seeing this all fixed, but someone is going to
> > have to find a middle ground that both meets the minimum sensible
> > expectations for distro Best Practice for this, and that Shigio is
> > willing to accept. Several of us have tried several times, but maybe
> > you will have more luck with that.
>
> The problem arises due to the expectation that the user needs to write
> to a priviledged system wide location. Instead, is it not preferable
> that the user generated content (the HTML folder and cgi scripts
> therein) be placed in the users web area (e.g., ~public_html) and it
> is served from there like any other user generated content. No
> priviledged access is required. Does that make sense?
Well ... no. That doesn't make any sense at all.
The cgi scripts run with the privilege of the web server. Which means
an audited copy of that needs to be installed and enabled by someone
with the privilege to decide whether or not that is acceptable.
And someone with similar privilege needs to decide what files it will
be allowed to access.
Which means all of this needs to:
a) Not be generated on the fly, so that the sysadmin can actually
audit it, and know that what they audited is what is running.
b) Not be world writable. Which is effectively what you'd be doing
if you let 'non-static' content run executables from ~pub_html
with elevated privilege.
None of this is rocket science to do. It just requires some acceptance
that sane security practices are actually important, and need to be
designed in from the beginning, not handwaved away as "too hard".
> > But we need to sort this out. Sweeping it under the rug is just code
> > for "This will never happen", so I will strongly object to any upload
> > that does this.
>
> Sweeping it under the run isn't my intention. I agree we need to
> resolve the issue. I'd appreciate your input on how it can be fixed
> properly.
If it isn't your intention, that's great, but that wasn't what your words
kept saying :)
I, and others, have said many times what is needed to do this sanely,
and the constraints above should not be that hard to satisfy. What has
so far proved impossible has been convincing Shigio that chmod 777 is
not an acceptable substitute for this. And I don't really know what else
I can say anymore that might change that.
Shigio, please reconsider. We have people prepared to spend time on this.
Let's use that to do this properly once and for all. Let's find an answer
that satisfies both basic security practices, and whatever it is that does
concern you about methods that would do that. bless.sh and chmod 777 do
not do that, so if you want to progress with this, we need to meet in the
middle somewhere with a modern design using current best practice.
Ron
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
