On 02.08.2015 23:15, Michael Schwendt wrote: > On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote: > >>>> A) if a shell script can be treated as configuration file? >>> >>> Certainly. It's a cheap way to set a program's runtime configuration >>> instead of implementing a full config file loader/parser. >> >> My image of configuration files is that they are files for read/write >> purpose by design, because they enables _configure_ something >> (application, service, single program, script...whatever). If they are >> dedicated only for reading then from my point of view they lose >> "configuration" meaning (something like WORM storage ;-) ). > > Why would you say that?
Hello Michael, I trying to express my opinion about my understanding 'configuration files' meaning. > There are read-only config files to set the system-wide default for > everyone. The program reads them first before looking for user's local > config files to override the defaults. The program would never write > the system-wide file file in /etc, but at most the user's local file. In my opinion that this type of files can be classified as pre-defined settings files, not configuration files. In any case, it looks that we have different understanding configuration files and it causes cross over our opinions. I think also that better could be set the environment variables values in /etc/defaults/ and use these values by shell scripts instead using hard-coded values in shell scripts. Coming back to profile.d sample, when somebody try to modify profile.d file marked as %config [not %config(noreplace)] then after upgrade package with new profile.d file version, the file will be overwritten and user will lose introduced changes. It seems that all this situation uncovers bigger problem :-) > And in general, whether a program can write its own config files is purely > a question of design. Clearly, over the years there have been programs that > only read config files somebody [or some tool] can create. > > /etc/bashrc, /etc/profile are examples of %config files where the file > format is shell language code to be interpreted by a shell. <cut> >> However I believe that exist some tools or libraries that can do this >> content analyze for rpmlint. > > What would be the benefit? rpmlint cannot get it 100% right > anyway. There could be corner-cases, where a config file gets executed > instead of being "sourced" like a shell include file. Yes, rpmlint cannot get it 100% right, but it can report potential executable files more accurate. If something can offload person, that for example do review request, from manual checking content of files, why not use it? >>> It's some sort of white-list to assume that files in /etc meant to be >>> executed (such as initscripts related files) are not configuration >>> files in any way. Admin may decide to edit such executables nevertheless >>> (for reasons unknown), but the next update would overwrite the changes. >> >> Good to know that mentioned white-list exists. Could you indicate me >> where can I find this white-list? > > With "some sort of white-list" I mean the simplification -- the > simplified assumption -- that files with execute permission are > believed to be executables and not configuration files. And vice > versa. Real configuration files being marked executable are believed > to be mistakes. OK. Thanks for clarify. Best regards. Marcin Haba
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
