Alvaro Lopez Ortega | 1 Sep 2008 09:03
Picon
Gravatar

Re: Logs owner

Antonio Pérez wrote:
> On Sun, Aug 31, 2008 at 7:18 PM, Alvaro Lopez Ortega <alvaro <at> gnu.org> wrote:
> 
>>> Anyone with this problem?.
>> Well, I'd say that's the expected behavior, actually.
>>
>> This is what is happening in your case:
>>
>>  1.- Cherokee is executed as root, but you want it to drop privileges
>>  2.- It opens the log files (as root)
>>  3.- It becomes www-data right after that
>>  4.- Works for a while, until it receives SIGUSR2
>>  5.- It tries to reopen the files but it cannot
>>
>> So, at least the issue is consistent with what you wanted it to do. If you
>> want the server to run as www-data, you cannot expect it to be able to
>> reopen root files.
> 
> So, why if it is running as www-data, it can write to log files owned
> by root but it can't do it when it receives SIGUSR1?.

Because it opened it while it was root. Then, it dropped the privileges 
and became www-data. So, from that point on there is no way it can 
become root again (that's the whole point to becoming another user).

> (Have you changed it now to SIGUSR2?).

Yes, only in trunk (the upcoming 0.9) though.  Yesterday I spent quite 
some time unifying the Cherokee interfaces; so, unless I have made a 
mistake it should remain like that.
(Continue reading)

Antonio Pérez | 1 Sep 2008 09:53

Re: Logs owner

On Mon, Sep 1, 2008 at 9:03 AM, Alvaro Lopez Ortega <alvaro <at> gnu.org> wrote:

>> So, why if it is running as www-data, it can write to log files owned
>> by root but it can't do it when it receives SIGUSR1?.
>
> Because it opened it while it was root. Then, it dropped the privileges and
> became www-data. So, from that point on there is no way it can become root
> again (that's the whole point to becoming another user).

Yes, I understand, and I think that it should create (when it not
exists) log files as www-data, so when it will have to reopen them, it
can.

>> (Have you changed it now to SIGUSR2?).
>
> Yes, only in trunk (the upcoming 0.9) though.  Yesterday I spent quite some
> time unifying the Cherokee interfaces; so, unless I have made a mistake it
> should remain like that.

Ok!.

>>> What would be for you the expected behavior?
>>
>> I expect this:
>>
>> 1.- Cherokee is executed as root, but I want it to drop privileges
>> 2.- It becomes www-data.
>> 3.- It opens the log files (as www-data)
>> 4.- Works for a while, until it receives SIGUSR2
>> 5.- It tries to reopen the files and it can.
(Continue reading)

Alvaro Lopez Ortega | 1 Sep 2008 09:59
Picon
Gravatar

Re: Logs owner

Antonio Pérez wrote:
> On Mon, Sep 1, 2008 at 9:03 AM, Alvaro Lopez Ortega <alvaro <at> gnu.org> wrote:
> 
>> Since it *IS* running as www-data, there is no way it can reopen a root file
>> with perms 644.
> 
> Sure!... but logs files "must" be created as www-data. I don't want
> this log files owned by root.

Ohh.. okay, now it does make sense. I did not get you the first time.
It sounds like a bug, actually. I'll check it out.

>> Have you done this with other software? I might be missing something.
> 
> I don't know... and I can't do too much to know at the moment, because
> I'm at the beach with an USB HSDPA modem and an "unbelievable" speed
> of 12Kbps!.

Ohhh damn, what a tough life you have! ;-)

--

-- 
Greetings, alo
http://www.alobbs.com/
Antonio Pérez | 1 Sep 2008 12:47

Re: Logs owner

>> Sure!... but logs files "must" be created as www-data. I don't want
>> this log files owned by root.
>
> Ohh.. okay, now it does make sense. I did not get you the first time.
> It sounds like a bug, actually. I'll check it out.

Thank you... I think that log files must be owned by the user that is
running Cherokee.

--

-- 
Saludos:
Antonio Pérez

ATENCIÓN: Antes de imprimir este mensaje valora si verdaderamente es necesario.
De esta forma contribuimos a la preservación del Medio Ambiente.
Miguel Angel | 1 Sep 2008 13:01
Picon
Gravatar

Re: Logs owner

My 2 cents:

I've checked my apache's (yes... i still have some...) and when I make them
run as www-data they write all log files as www-data / www-data. :-)


2008/9/1 Antonio Pérez <aplistas <at> skarcha.com>
>> Sure!... but logs files "must" be created as www-data. I don't want
>> this log files owned by root.
>
> Ohh.. okay, now it does make sense. I did not get you the first time.
> It sounds like a bug, actually. I'll check it out.

Thank you... I think that log files must be owned by the user that is
running Cherokee.

--
Saludos:
Antonio Pérez

ATENCIÓN: Antes de imprimir este mensaje valora si verdaderamente es necesario.
De esta forma contribuimos a la preservación del Medio Ambiente.
_______________________________________________



--
Miguel Angel Ajo Pelayo
http://optimizacionweb.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
Alvaro Lopez Ortega | 1 Sep 2008 13:13
Picon
Gravatar

Re: Logs owner

Miguel Angel wrote:
> 2008/9/1 Antonio Pérez <aplistas <at> skarcha.com <mailto:aplistas <at> skarcha.com>>
> 
>      >> Sure!... but logs files "must" be created as www-data. I don't want
>      >> this log files owned by root.
>      >
>      > Ohh.. okay, now it does make sense. I did not get you the first time.
>      > It sounds like a bug, actually. I'll check it out.
> My 2 cents:
> 
> I've checked my apache's (yes... i still have some...) and when I make them
> run as www-data they write all log files as www-data / www-data. :-)

r1930 has fixed it. Thanks for reporting guys!

--

-- 
Greetings, alo
http://www.alobbs.com/
Gunnar Wolf | 2 Sep 2008 02:07
Gravatar

Debian still shipping 0.7.x

Hi,

It's been a couple of weeks already, and I still have not uploaded
0.8.x into Debian - I know many of you (thanks!) have Debian as your
distribution of choice, so I think I should explain a bit.

I noticed there were several shortcomings on the quality of the work I
did as a packager, mostly regarding the transition from 0.5.x to the
current release. As many of you know, Debian has already entered the
freeze towards our next major release, Lenny - Just before Cherokee
0.8 was published. Our release policies mandate that we should stick
with the version currently in the archive, so I am not yet uploading
0.8. 

As I said, there were several pitfalls for 0.5->0.7 upgrades, and some
other Debian policy aspects I had not taken care of
(i.e. byte-compiling the Python modules for the administrative
interface upon installation). The Release Team asked me to do an
upload with those aspects fixed, and only when that version is
accepted into Lenny (which I expect to happen during this week), I
will upload 0.8 into Unstable.

Of course, I have found some (minor) details regarding some of the
scripts' workings - I will send them over here as soon as I'm sure 
what I'm doing is correct ;-)

Greetings,

--

-- 
Gunnar Wolf - gwolf <at> gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
Beech Rintoul | 2 Sep 2008 05:41

Re: Debian still shipping 0.7.x

On Monday 01 September 2008, Gunnar Wolf said:
> Hi,
>
> It's been a couple of weeks already, and I still have not uploaded
> 0.8.x into Debian - I know many of you (thanks!) have Debian as
> your distribution of choice, so I think I should explain a bit.
>
> I noticed there were several shortcomings on the quality of the
> work I did as a packager, mostly regarding the transition from
> 0.5.x to the current release. As many of you know, Debian has
> already entered the freeze towards our next major release, Lenny -
> Just before Cherokee 0.8 was published. Our release policies
> mandate that we should stick with the version currently in the
> archive, so I am not yet uploading 0.8.
>
> As I said, there were several pitfalls for 0.5->0.7 upgrades, and
> some other Debian policy aspects I had not taken care of
> (i.e. byte-compiling the Python modules for the administrative
> interface upon installation). The Release Team asked me to do an
> upload with those aspects fixed, and only when that version is
> accepted into Lenny (which I expect to happen during this week), I
> will upload 0.8 into Unstable.
>
> Of course, I have found some (minor) details regarding some of the
> scripts' workings - I will send them over here as soon as I'm sure
> what I'm doing is correct ;-)
>
> Greetings,

I would like to see Cherokee incorporate this into their install. 
Compiling by starting the admin binary isn't an option for a FreeBSD 
install so I did the following:

 <at> cd ${DATADIR}/admin && ${FIND} . -name "*.py" |\
	${XARGS} ${PYTHON_CMD} ${PYTHON_LIBDIR}/py_compile.py

I would imagine that this is also an issue with other dists.

Beech

--

-- 
---------------------------------------------------------------------------------------
Beech Rintoul - FreeBSD Developer - beech <at> FreeBSD.org
/"\   ASCII Ribbon Campaign  | FreeBSD Since 4.x
\ / - NO HTML/RTF in e-mail   | http://people.freebsd.org/~beech
 X  - NO Word docs in e-mail | Skype: akbeech
/ \  - http://www.FreeBSD.org/releases/7.0R/announce.html
---------------------------------------------------------------------------------------
Alvaro Lopez Ortega | 2 Sep 2008 11:51
Picon
Gravatar

Re: Debian still shipping 0.7.x

Beech Rintoul wrote:
> On Monday 01 September 2008, Gunnar Wolf said:
>>
>> As I said, there were several pitfalls for 0.5->0.7 upgrades, and
>> some other Debian policy aspects I had not taken care of
>> (i.e. byte-compiling the Python modules for the administrative
>> interface upon installation).
> 
> I would like to see Cherokee incorporate this into their install. 
> Compiling by starting the admin binary isn't an option for a FreeBSD 
> install so I did the following:
> 
>  <at> cd ${DATADIR}/admin && ${FIND} . -name "*.py" |\
> 	${XARGS} ${PYTHON_CMD} ${PYTHON_LIBDIR}/py_compile.py
> 
> I would imagine that this is also an issue with other dists.

It is a known issue, actually:

   http://code.google.com/p/cherokee/issues/detail?id=79

When I first looked at it, I was not sure about how it should be fixed, 
actually. The  main issue is that even if the Automake Python support 
does everything for us (byte-compiling, pyc files clean up and so on), 
it tries to install cherokee-admin as a Python module rather than in its 
target directory (usually /usr/share/cherokee/admin).

Have you guys experience with this? I would only agree on adding the 
manual clean up command if there is no way to point Automake to use the 
'right' installation path. Otherwise it'd be much cleaner to relay on 
Automake for this stuff.

--

-- 
Greetings, alo
http://www.alobbs.com/
Beech Rintoul | 2 Sep 2008 21:01
X-Face

Re: Debian still shipping 0.7.x

On Tuesday 02 September 2008, Alvaro Lopez Ortega said:
> Beech Rintoul wrote:
> > On Monday 01 September 2008, Gunnar Wolf said:
> >> As I said, there were several pitfalls for 0.5->0.7 upgrades,
> >> and some other Debian policy aspects I had not taken care of
> >> (i.e. byte-compiling the Python modules for the administrative
> >> interface upon installation).
> >
> > I would like to see Cherokee incorporate this into their install.
> > Compiling by starting the admin binary isn't an option for a
> > FreeBSD install so I did the following:
> >
> >  <at> cd ${DATADIR}/admin && ${FIND} . -name "*.py" |\
> > 	${XARGS} ${PYTHON_CMD} ${PYTHON_LIBDIR}/py_compile.py
> >
> > I would imagine that this is also an issue with other dists.
>
> It is a known issue, actually:
>
>    http://code.google.com/p/cherokee/issues/detail?id=79
>
> When I first looked at it, I was not sure about how it should be
> fixed, actually. The  main issue is that even if the Automake
> Python support does everything for us (byte-compiling, pyc files
> clean up and so on), it tries to install cherokee-admin as a Python
> module rather than in its target directory (usually
> /usr/share/cherokee/admin).
>
> Have you guys experience with this? I would only agree on adding
> the manual clean up command if there is no way to point Automake to
> use the 'right' installation path. Otherwise it'd be much cleaner
> to relay on Automake for this stuff.

I ran into exactly that problem with our py install software, hence 
the extra step. Our problem was after a user ran the admin binary and 
then deinstalled the port there were about 20 .pyc files left behind. 
I could have put a check and some makefile magic to deal with that, 
but it was easier just to byte compile the .py files and be done with 
it. 

As for automake dealing with it, I'm not sure if it's capable of that, 
but having the application use the default install path as a target 
would be ok. We have to patch the paths anyway because our path is 
slightly different than the linux dists (/usr/local/share).

I did look at several py ports to see if there was an easier way to 
compile that directory, but our system is set up to deal with that as 
a python module also, so byte compiling after install was my only 
option.

That being said, after some tweaking I moved 0.8x to our main port and 
except for a couple of minor issues (fixed) our users are very happy 
with it. I also removed the -devel version because I didn't feel it 
was needed anymore. We are also about to go into a code freeze for 
the new releases and I wanted to make sure Cherokee-0.8 was included.

The only other request I've been getting is to make the admin install 
optional for users who already have cherokee installed or want to 
configure by hand. I haven't looked at that closely, but I don't 
remember seeing a --with-cherokee-admin knob. So that may take a bit 
of work.

Beech

--

-- 
---------------------------------------------------------------------------------------
Beech Rintoul - Sys. Administrator - beech <at> alaskaparadise.com
/"\   ASCII Ribbon Campaign  | Alaska Paradise
\ / - NO HTML/RTF in e-mail  | 201 East 9Th Avenue Ste.310
 X  - NO Word docs in e-mail | Anchorage, AK 99501
/ \  - Please visit Alaska Paradise - http://www.alaskaparadise.com
---------------------------------------------------------------------------------------

Gmane