I read :
"The web user should be allowed the write permission on the following directories, under the iTop root : root directory (iTop Hub connector will remove the env-production-build directory before compiling)"
This is not very easy to apply (and it seems to me a little strange, in a security perspective).
The temporary creation an deletion of a directory is not a problem to me (but I'm not a security expert), but that should be in a specific subdir.
I didn't dig in the source code, but moving all env-* dir in a specific subdir (env, maybe :) should not be a considerable work ?
I can totally undersand that this is not of top priority, especially with the upcoming iTop 3.0, but could you have a look at that ?
Many, many thanks,
Pascal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you detail the problem you ran into caused by this write permission ?
I remember Vladimir did some digging with Docker, and we have some clients that are running iTop in containers too...
The biggest issue with changing this would be the installed base...
However I've forwarded your message to the dev team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm also able to run iTop in containers but I have to do some 'magic' for that :
Basically :
Typically, you put in your containers all the static files (the iTop distro mainly, and, depending on your local policy, the extension folder can be part of the static packages or not, depending if you choose to consider each extension delivery as a part of your iTop package or not.
For the 'changing datas', you add one ore more 'persistent volumes', that are outside of the container.
And you 'link' the changing files or folders in that persistent storage.
That way, you separate dthe code from the data. Also, it's always possible to reload the container, as the data inside the container are static.
So supposing that you install itop in the /itop folder of your container
You create a persistent volume, and define that /itop/conf is actually a folder in the persistent volume (an the same for data, logs, extensions -or not, your choice :) )
But it's not easy to find a way to deal with the same thing if a directory (that should be in the permanent storage, on maybe in that case in some sort of memory drive) is subject to creation/rename/deletion
Also, even in non containerized environment, I'm not so found of the idea that the webserver account has a read/write accesss to the top of the web structure.
I'm not sure that my explanation is quite understandable, don't hesitate if you need more information !
And thanks anyway for the follow-up.
Pascal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you build your containers with anything you want, iTop compilation has to be ran. The env-* folders are the results of this compilation process. They don't contains 'datas' (like UR content for example), but compiled files (briefly said : a merging of XML files, then a compilation of XML to PHP).
The result of the compilation depends only of the iTop package : you will only have one result for a given set of iTop core and modules.
Do you have something else in mind ?
The conf is indeed another subject...
And we can also discuss on the possibility to add new extension and relaunch a compilation (using the Hub container for example)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just got the Dockerfile from Vladimir, and he doesn't have my kind of trouble, he didn't seperate data and code.
That's totally okay, I get it. But it's not exactly the way we deal with our Kubernetes clusters.
Basically, the persistent storage need to be separated from the container, as you never know where the container will start inside the cluster (A little overdramatic, but you got the idea :) )
Pascal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to automate iTop deployment (namely put iTop in containers).
I have a problem with the iTop need to have a read/write access to the root directory :
In this (nice) document : https://www.itophub.io/wiki/page?id=latest%3Ainstall%3Asecurity
I read :
"The web user should be allowed the write permission on the following directories, under the iTop root :
root directory (iTop Hub connector will remove the env-production-build directory before compiling)"
This is not very easy to apply (and it seems to me a little strange, in a security perspective).
The temporary creation an deletion of a directory is not a problem to me (but I'm not a security expert), but that should be in a specific subdir.
I didn't dig in the source code, but moving all env-* dir in a specific subdir (env, maybe :) should not be a considerable work ?
I can totally undersand that this is not of top priority, especially with the upcoming iTop 3.0, but could you have a look at that ?
Many, many thanks,
Pascal
Hello Pascal,
Can you detail the problem you ran into caused by this write permission ?
I remember Vladimir did some digging with Docker, and we have some clients that are running iTop in containers too...
The biggest issue with changing this would be the installed base...
However I've forwarded your message to the dev team
Hi Pierre,
I'm also able to run iTop in containers but I have to do some 'magic' for that :
Basically :
Typically, you put in your containers all the static files (the iTop distro mainly, and, depending on your local policy, the extension folder can be part of the static packages or not, depending if you choose to consider each extension delivery as a part of your iTop package or not.
For the 'changing datas', you add one ore more 'persistent volumes', that are outside of the container.
And you 'link' the changing files or folders in that persistent storage.
That way, you separate dthe code from the data. Also, it's always possible to reload the container, as the data inside the container are static.
So supposing that you install itop in the /itop folder of your container
You create a persistent volume, and define that /itop/conf is actually a folder in the persistent volume (an the same for data, logs, extensions -or not, your choice :) )
But it's not easy to find a way to deal with the same thing if a directory (that should be in the permanent storage, on maybe in that case in some sort of memory drive) is subject to creation/rename/deletion
Also, even in non containerized environment, I'm not so found of the idea that the webserver account has a read/write accesss to the top of the web structure.
I'm not sure that my explanation is quite understandable, don't hesitate if you need more information !
And thanks anyway for the follow-up.
Pascal
As you build your containers with anything you want, iTop compilation has to be ran. The env-* folders are the results of this compilation process. They don't contains 'datas' (like UR content for example), but compiled files (briefly said : a merging of XML files, then a compilation of XML to PHP).
The result of the compilation depends only of the iTop package : you will only have one result for a given set of iTop core and modules.
Do you have something else in mind ?
The conf is indeed another subject...
And we can also discuss on the possibility to add new extension and relaunch a compilation (using the Hub container for example)
Okay :)
I just got the Dockerfile from Vladimir, and he doesn't have my kind of trouble, he didn't seperate data and code.
That's totally okay, I get it. But it's not exactly the way we deal with our Kubernetes clusters.
Basically, the persistent storage need to be separated from the container, as you never know where the container will start inside the cluster (A little overdramatic, but you got the idea :) )
Pascal