[Kolab-devel] [PATCH] better modes

Gunnar Wrobel wrobel at pardus.de
Wed Jun 9 21:08:52 CEST 2010


Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> * Gunnar Wrobel <wrobel at pardus.de> [20100603 15:50]:
>> Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
>>
>>> Attached is a patch to apply to kolabd/kolabd/Makefile.am.
>>>
>>> 1) Installing a file chmod 444 prevents build processes from changing any
>>> ownership attributes and modes
>>>
>>> 2) If you can read it, you can execute it.
>>
>> Thanks! Commited to CVS.
>>
>> Concerning kolab.globals I'm not 100% certain everyone agrees to the
>> change. It has been added by Richard Bos not too long ago (which is why I
>> added him on cc). In principle you should never really change
>> kolab.globals and mode 444 was intended to indicate that. The file is
>> specific to your distribution and there are usually no reasons to modify
>> it.
>
> And I am still unsure about that.
>
> I do not understand "444 prevents build processes from changing any
> ownership attributes and modes". What exactly does not work?
>
>> The file lies in /etc though and it also has a few variable (e.g.
>> "log_level" or "debug") that can/should be touched by the sysadmin under
>> certain circumstances. So I think mode 644 makes more sense for the file.
>
> No, you should simply copy those lines to kolab.conf and modify them
> to your needs.
>
>> It is probably better to add a header to that files that explicitely
>> states that it is not intended for modification.
>
> That's probably good, too :)
>

Ah, makes sense. So my argument is invalidated and I guess 444 was
indeed the correct value. I did add a short paragraph to kolab.globals
now. It explains that any modifications should go into kolab.conf.

Other than that I would suggest to wait for Jeroens response before
potentially reverting to 444 again.

Cheers,

Gunnar

>> A general remark: Patches for the Kolab server should better go into a
>> separate issue on issues.kolab.org. The mailing list gets a notification
>> automatically and chances that your patch gets forgotten are
>> significantly lower.
>
> I did not forget this patch, I just saw more need for discussion
> than available time. But yes, using the issues.kolab.org might be
> good for tracking the progress.
>
> Regarding "2) If you can read it, you can execute it.":
> Sure, but with this you can indicate that this should not be
> executed by anyone. But I have no problem with this change, these
> scripts are probably not important enough to discuss them.
>
> Regards,
> Thomas
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100609/148849d2/attachment.sig>


More information about the devel mailing list