On Fri, Apr 11, 2014 at 1:55 PM, Ron <r...@debian.org> wrote: > On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote: >> On Fri, Apr 11, 2014 at 11:31 AM, Ron <r...@debian.org> 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. >
I've been using global for over a year now. And in all that usage I've never had to run anything as root. When you off-handedly mentioned a generated script being required to be run as root I didn't even know what you were talking about. Neither did you reply to my query asking for further clarification. When faced with this situation and not knowing how to move things forward I'd suggested turning it off. And Shigio in his reply agrees that this isn't a bad option as it isn't even used that widely. > 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. > The current package in debian is broken - even the tags functionality is broken. The problem doesn't exist in upstream release. I am in favour of solving the problem you point out, but at the same time I don't agree with holding back a package update which fixes a problem for users, especially when there isn't a resolution in >3.5 years. > >> > 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 :) > Only because there doesn't seem to be a resolution in the 3.5 years that have passed. I'd like to hope that things can move forward from here. Punit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
