From: JupiterHost.Net <ml...@ju...> - 2005-12-04 01:15:35
|
Hello list :) Say I have a config file that I want a user to be able to specify some options but not others. What I was thinking was in the main config file (which the user can read but not write) I'd specify the options that I don't want them to be able to change and use include: to let them specify any other options in a file they can write to. My question is: Would it be better to put the include before or after the other directives? Say they specify "whatever:" in their file but I don't want to allow them to change or specify "whatever:" # if htdig uses the first instance of it then I need to specify it first: whatever: they shouldn't be able to change this include: their/file or # if htdig uses the last instance of it then I need to specify it last to override anything they put in: include: their/file whatever: they shouldn't be able to change this So which way should I do it to acheive that (IE preventing the include: from overriding certain options) and is that even possible? Danke :) |
From: JupiterHost.Net <ml...@ju...> - 2005-12-06 19:36:17
|
Neal Richter wrote: > Interesting idea. > > One solution to this would be to build a quick PHP script that would > allow users to manipulate the setting you want them > to then save them in the htdig.conf file. but then PHP (IE usually "nobody" (pronounced *everybody*) has to have write access to it which means anyone can change anything they want) Something that important needs done by a real language with less security exploits, IMHO > At one time someone build a PHP wrapper for configuring htdig.. this > would be a good starting point. I can't seem to find the code.. yet. No need for any sort of special editor or interface, just in the config file they do not have write access to does it need to be A or B: a) if htdig uses the first instance of it then I need to specify it first: whatever: they shouldn't be able to change this include: their/file b) if htdig uses the last instance of it then I need to specify it last to override anything they put in: include: their/file whatever: they shouldn't be able to change this Which way would make it so that even if they specified "whatever:" it woudl still use the "whatever:" in the main config that they do not have access to? |
From: Kurt C. <kur...@wr...> - 2005-12-07 14:20:05
|
JupiterHost.Net wrote: > > No need for any sort of special editor or interface, just in the config > file they do not have write access to does it need to be A or B: > > a) if htdig uses the first instance of it then I need to specify it first: > > whatever: they shouldn't be able to change this > include: their/file > > > b) if htdig uses the last instance of it then I need to specify it last > to override anything they put in: > > include: their/file > whatever: they shouldn't be able to change this > > Which way would make it so that even if they specified "whatever:" it > woudl still use the "whatever:" in the main config that they do not have > access to? > > From the definition of "include" at <http://www.htdig.org/confindex.html> "The last definition of an attribute is the one that applies, so after including a file, any of its definitions can be overridden with subsequent definitions. This can be useful when setting up many configurations that are mostly the same, so all the common attributes can be maintained in a single configuration file. The include directives can be nested, but watch out for nesting loops." So, according to that, anything you do not want the user to be able to change would need to be after the include statement, which would be option "B" above. This paragraph does bring up the interesting point of what could happen if the user adds an include that references the main config file: common.conf -> include: user.conf user.conf -> include: common.conf I don't know exactly how that would manifest itself, but I imagine it wouldn't be a good thing. Kurt |
From: JupiterHost.Net <ml...@ju...> - 2005-12-07 14:40:57
|
>> b) if htdig uses the last instance of it then I need to specify it last >> to override anything they put in: >> >> include: their/file >> whatever: they shouldn't be able to change this >> >> Which way would make it so that even if they specified "whatever:" it >> woudl still use the "whatever:" in the main config that they do not >> have access to? >> >> > > From the definition of "include" at <http://www.htdig.org/confindex.html> > > "The last definition of an attribute is the one that applies, so after > including a file, any of its definitions can be overridden with > subsequent definitions. This can be useful when setting up many > configurations that are mostly the same, so all the common attributes > can be maintained in a single configuration file. The include directives > can be nested, but watch out for nesting loops." > > So, according to that, anything you do not want the user to be able to > change would need to be after the include statement, which would be > option "B" above. Excellent! Exactly what I'd been looking for :) although that text isn't at that url for me, weird?? > This paragraph does bring up the interesting point of what could happen > if the user adds an include that references the main config file: > > common.conf -> include: user.conf > user.conf -> include: common.conf > > I don't know exactly how that would manifest itself, but I imagine it > wouldn't be a good thing. Good point, I'll have to consider that as well. At least a big fiery warning that says: You will 100% guaranteed break your config if you include: the configuration file that uses this file. Thanks again Kurt! |
From: Kurt C. <kur...@wr...> - 2005-12-07 15:00:33
|
JupiterHost.Net wrote: > Excellent! Exactly what I'd been looking for :) although that text isn't > at that url for me, weird?? > I should have mentioned that once you click on <http://www.htdig.org/confindex.html>, then you click on "Alphabetical" over on the left-hand side, under "Attributes", then scroll down and click on "include". >> This paragraph does bring up the interesting point of what could >> happen if the user adds an include that references the main config file: >> >> common.conf -> include: user.conf >> user.conf -> include: common.conf >> >> I don't know exactly how that would manifest itself, but I imagine it >> wouldn't be a good thing. > > > Good point, I'll have to consider that as well. At least a big fiery > warning that says: > You will 100% guaranteed break your config if you include: the > configuration file that uses this file. > > Thanks again Kurt! > You're welcome. Kurt |
From: JupiterHost.Net <ml...@ju...> - 2005-12-07 15:32:59
|
Kurt Cypher wrote: > JupiterHost.Net wrote: > >> Excellent! Exactly what I'd been looking for :) although that text >> isn't at that url for me, weird?? >> > I should have mentioned that once you click on > <http://www.htdig.org/confindex.html>, then you click on "Alphabetical" > over on the left-hand side, under "Attributes", then scroll down and > click on "include". No worries, I should've used a bit of common sense to figure out where include was documented :) Have a great day Kurt |
From: JupiterHost.Net <ml...@ju...> - 2005-12-07 23:32:47
|
Neal Richter wrote: > If you are dilligent enough in verifying input from the user you can > lock-down what the user could enter to the file. You could also have a > process to copy the user/PHP created script to the main htdig.conf file > to further isolate it. Put PHP's security problems aside, if the file is owned by the user or nobody (IE the script can write to it) then the user can open it in a text editor via SSH and change it, so all the hours you'd spend limiting, checking and hoping you didn't miss any sort of "bad entry" injection, is all for naught because they have write access to it. > I understand your idea. It's a good idea. I am trying to come up with > a work-alike for you, as it's unlikely that the idea will be implemented > in 3.1.6 or 3.2.bx. I don't need an interface to edit a config file (which in itself isn't a bad idea and has been done) I needed to know for sure if: include: file/they/can/write/to/by/whatever/means.conf important: they should not be able to change this via their include then they can put whatver they want in file/they/can/write/to/by/whatever/means.conf and "important" will always be "they should not be able to change this via their include" > The other alternative is to set up the defaults.cc file how you want it > and make a custom binary, then the htdig.conf file would only contain > the user overrides you allow. A perl script could validate that only a > discrete set of configs are contained in the file and filter-out others > before passing to htsearch via a command-line switch. htdig -c xxx.conf. To much work and ways to get around it still :), just: include: file/they/have/write/access/to.conf # directives you don't want chanegd here then you're directives are "safe" and there's zero overhead mainteneance wise because only I can write to the file described above. What *would* be a nice addition to htdig is to make it catch include: loops: in main.conf include: user.conf in user.conf include: main.conf it'd include user.conf and when it got to the include: user.conf line throw a warning/log that main.conf is already part of the party and then ignore it. That'd be trivial to do and would be extremely handy :) Thanks for the input though |