Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-13 11:57 AM, André Warnier wrote: Yes, I cannot really think off-hand of any serious problem that this may cause. Basically, it all depends on the context. If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that). But it is not critical. This is not my context. Another context entirely is if this is a professional website This is my context. that you are setting up for an important customer which you cannot afford to lose, This is not my context. The website is for my company. or if this is a design pattern for an application which you intend to reproduce hundreds of times in the future. Maybe not hundreds of times but several times possibly. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux. (umask for example would not). That's right. And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is writeable by group. I understand. Are you thinking about tiger? Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. This is not my case. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir. Your choice. Only I can add files to the webapp exploded directory. If the other webapp users upload files on the server it won't be into the webapp exploded directory. I hope it won't hurt if I grant the write privilege to the owner group of the exploded webapp directory... Otherwise, only tomcat6 and root can write to this directory. And as tomcat6 can't have a shell, only root can actually do this (distantly using WinSCP or SCP in my case and it's not safe to log in as root in these cases). This is why I added a simple user (not root) to the tomcat6 group. Only this simple user has the write permission on the exploded webapp directory as a member of the tomcat6 group. Best regards, -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-13 12:03 PM, André Warnier wrote: On 2014-03-12 11:49 PM, Neven Cvetkovic [via Tomcat] wrote: How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Yes, well, how shall I do that? Personally, I don't think you should. The scary thing here is All newly created files. That means e.g. all webapps deployed by Tomcat, not just your my_webapp. But if you wanted to do it nevertheless, under Linux you would do that in the /etc/init.d script which starts Tomcat. Ok. Thank you. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: On 2014-03-13 11:57 AM, André Warnier wrote: Yes, I cannot really think off-hand of any serious problem that this may cause. Basically, it all depends on the context. If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that). But it is not critical. This is not my context. Another context entirely is if this is a professional website This is my context. that you are setting up for an important customer which you cannot afford to lose, This is not my context. The website is for my company. In the possible consequences, it is quite similar, no ? or if this is a design pattern for an application which you intend to reproduce hundreds of times in the future. Maybe not hundreds of times but several times possibly. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux. (umask for example would not). That's right. And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is writeable by group. I understand. Are you thinking about tiger? I wasn't thinking about any auditing software in particular. But most of them will scan the permissions of a set of well-know directories (and tomcat/webapps would be one of those) and flag anything that they consider suspicious or non-standard. By the Java Servlet Specification, the webapps directories would not normally be writeable, so this may come up. Which, in the best of cases, would result in you having to write a report describing why you needed to set the permissions that way. Which is probably not the kind of thing at which you want to spend your time. But maybe your company does not do this kind of audit, in which case all that is irrelevant. I just wanted to warn you of the possibility. I do actually have a couple of customers where this would be a definite no-no. (There is also the possibility of a colleague of yours, seeing those permissions in 6 months time while you are on holiday, and re-setting them properly..) Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. This is not my case. Rules can be broken, if there is enough justification. What I meant was that strictly going by the rules, making your webapp's directory writeable is not something which you should be doing, because in theory this is not something which you can always expect to be possible. You have now described your context in more detail, and now we know that this is not an application which you would distribute to work on some kind of mobile device where it would be stored on some non-writeable ROM device. But before the latest explanation, we did not know that. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir. Your choice. Only I can add files to the webapp exploded directory. If the other webapp users upload files on the server it won't be into the webapp exploded directory. I hope it won't hurt if I grant the write privilege to the owner group of the exploded webapp directory... Otherwise, only tomcat6 and root can write to this directory. And as tomcat6 can't have a shell, only root can actually do this (distantly using WinSCP or SCP in my case and it's not safe to log in as root in these cases). This is why I added a simple user (not root) to the tomcat6 group. Only this simple user has the write permission on the exploded webapp directory as a member of the tomcat6 group. Right. In your particular context and as you describe it above, it does not seem that it would hurt. Please understand that we still don't know exactly the whole practical context in which all of this lives. For example, we do not know if what you are trying to achieve is some kind of website where users can upload their own HTML pages, or whether this is some kind of repository where users can upload office documents to share between them, or if you are trying to replace Sharepoint as a collaborative tool, or whatever. Nor do we know if this has to be
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-14 12:45 PM, André Warnier wrote: Lmhelp1 wrote: On 2014-03-13 11:57 AM, André Warnier wrote: Yes, I cannot really think off-hand of any serious problem that this may cause. Basically, it all depends on the context. If this is a one-off thing that you are doing, on your personal website, on a server on which there is no really critical information and which is not open to all on the Internet etc.. then it is one context. You still have to be a bit careful so that this does not make your server into an ideal base for a hacker, to use it to do nasty things elsewhere. And you don't want to open your site to script kiddies who have nothing better to do in life than crashing other people's work (there are people like that). But it is not critical. This is not my context. Another context entirely is if this is a professional website This is my context. that you are setting up for an important customer which you cannot afford to lose, This is not my context. The website is for my company. In the possible consequences, it is quite similar, no ? or if this is a design pattern for an application which you intend to reproduce hundreds of times in the future. Maybe not hundreds of times but several times possibly. In that case, you want something that is airtight, that you can easily reproduce, update and maintain, and that will work under Windows as well as Linux. (umask for example would not). That's right. And you would also want something that is not going to be constantly flagged as insecure by security audit programs. They may have a set pattern of permissions that they expect, and they might not like that your webapp directory is writeable by group. I understand. Are you thinking about tiger? I wasn't thinking about any auditing software in particular. But most of them will scan the permissions of a set of well-know directories (and tomcat/webapps would be one of those) and flag anything that they consider suspicious or non-standard. By the Java Servlet Specification, the webapps directories would not normally be writeable, so this may come up. Which, in the best of cases, would result in you having to write a report describing why you needed to set the permissions that way. Which is probably not the kind of thing at which you want to spend your time. But maybe your company does not do this kind of audit, in which case all that is irrelevant. I just wanted to warn you of the possibility. I do actually have a couple of customers where this would be a definite no-no. (There is also the possibility of a colleague of yours, seeing those permissions in 6 months time while you are on holiday, and re-setting them properly..) Also, there is no guarantee that the webapps directory of a servlet engine would be writeable at all. It could be located on some read-only device or filesystem. This is not my case. Rules can be broken, if there is enough justification. What I meant was that strictly going by the rules, making your webapp's directory writeable is not something which you should be doing, because in theory this is not something which you can always expect to be possible. You have now described your context in more detail, and now we know that this is not an application which you would distribute to work on some kind of mobile device where it would be stored on some non-writeable ROM device. But before the latest explanation, we did not know that. In theory, the webapps directory is supposed to contain only *code* to be executed and parameters to be read, not writeable data. For a writeable area, the servlet container offers specific writeable work directories (for temporary files etc.), which are *not* under the ../webapps/ dir. Your choice. Only I can add files to the webapp exploded directory. If the other webapp users upload files on the server it won't be into the webapp exploded directory. I hope it won't hurt if I grant the write privilege to the owner group of the exploded webapp directory... Otherwise, only tomcat6 and root can write to this directory. And as tomcat6 can't have a shell, only root can actually do this (distantly using WinSCP or SCP in my case and it's not safe to log in as root in these cases). This is why I added a simple user (not root) to the tomcat6 group. Only this simple user has the write permission on the exploded webapp directory as a member of the tomcat6 group. Right. In your particular context and as you describe it above, it does not seem that it would hurt. Please understand that we still don't know exactly the whole practical context in which all of this lives. For example, we do not know if what you are trying to achieve is some kind of website where users can upload their own HTML pages, or whether this is some kind of repository where users can upload office documents to share between them, or if you are trying to replace Sharepoint as a collaborative tool, or whatever. Nor do we know if
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-12 11:32 PM, André Warnier [via Tomcat] wrote: Ok, I understand : the target directory is not created by you, it is created by Tomcat, so Tomcat sets these permissions, and they do not fit what you want to be able to do. That's it, I only miss the write permission for the owner group which is tomcat6. First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to set these permissions differently when it creates that directory as a result of the deployment of your webapp's war-file. Ok. This is what I was looking for. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). For now, I do a chmod g+w my_webapp manually. One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where it does this, modify that code, and build your own modified Tomcat. But that way is hard and full of accidents waiting to happen, so you probably don't want to do that. Yes, indeed. Another way would be to change the way in which you deploy your webapp, and that way itself subdivides into several sub-ways : 1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could already explode that webapp.war yourself, and deploy your application statically. That is, already create in advance the directory .../webapps/my_webapp, with the exploded contents of your war-file in it. You could then set the permissions of the my_webapp directory once and for all, and Tomcat would probably not re-set them. I see. 2) you could use a script to deploy your war-file programmatically, using the Tomcat Manager application to do it. Tomcat would explode the war-file (creating the webapps/my_webapp dir in the process, with permissions 755); and then your script would re-set these permissions to what you want. I see. 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. Another way would be to change the way in which your webapp my_webapp works. (And here I assume that these files are static files - like images or html files, but not JSP files). Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/, and leave it to Tomcat to serve those file when a browser requests them. Instead of that, you could have an active webapp my_webapp, which responds to browser requests for those files, and which actively reads them and returns them to the client. In such a case, the files would not need to be directly under ../webapps/my_webapp/, they could be anywhere, including in some separate directory (preferably even not under the top Tomcat directory), where your active webapp can find them. And that directory could have the permissions that you want, and Tomcat would never touch it. To be clean and flexible, the path to that directory could be in a parameter in your webapp's web.xml, which would be read by your active webapp, and that is where it would look for those files. I am sure that there are several cleverer ways to achieve the same result without having to do any real additional programming. For example by using a servlet filter inserted around your webapp, and which would do the real work (e.g. look up for UrlRewriteFilter in Google; it may well allow to do that kind of thing). You may even find a way to cleverly use some code to modify on-the-fly the location where Tomcat will look for the file (your appropriately permissive directory, where you moved the files), and then let Tomcat return it to the browser anyway. (That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. But I digress, this is a Tomcat list). I believe that another way (at least under Tomcat 7 (the current version), may be to use the aliases attribute in the Context descriptor of your application. See : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html to understand how Tomcat deploys an application, and where that Context descriptor would need to be. (Nite: you need to verify this, I have never used aliases under Tomcat and I do not really know if that would be usable here). The one solution which gives you the most control is the one where your own my_webapp webapp is the one which actually reads and returns the files to the browser, because that is your code, and you can bend it in any way you want. (Including for example, returning something nice to the client, when the file that he wants is not there). Another time maybe :). Be careful that changing the permissions of your webapps/my_webapp directory itself, may weaken the security of your Tomcat website, because there may be other things in there than the files which you intend to serve to the clients. That's why having these files somewhere else than directly under webapps/my_webapp may be preferable in any case. It
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Hello and thank you for your answer. On 2014-03-12 11:49 PM, Neven Cvetkovic [via Tomcat] wrote: How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Yes, well, how shall I do that? Who is placing these files into the webapp folder? I am manually placing my_webapp.war in the Tomcat6 webapps folder. Best regards. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: On 2014-03-12 11:32 PM, André Warnier [via Tomcat] wrote: Ok, I understand : the target directory is not created by you, it is created by Tomcat, so Tomcat sets these permissions, and they do not fit what you want to be able to do. That's it, I only miss the write permission for the owner group which is tomcat6. First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to set these permissions differently when it creates that directory as a result of the deployment of your webapp's war-file. Ok. This is what I was looking for. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). For now, I do a chmod g+w my_webapp manually. One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where it does this, modify that code, and build your own modified Tomcat. But that way is hard and full of accidents waiting to happen, so you probably don't want to do that. Yes, indeed. Another way would be to change the way in which you deploy your webapp, and that way itself subdivides into several sub-ways : 1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could already explode that webapp.war yourself, and deploy your application statically. That is, already create in advance the directory .../webapps/my_webapp, with the exploded contents of your war-file in it. You could then set the permissions of the my_webapp directory once and for all, and Tomcat would probably not re-set them. I see. 2) you could use a script to deploy your war-file programmatically, using the Tomcat Manager application to do it. Tomcat would explode the war-file (creating the webapps/my_webapp dir in the process, with permissions 755); and then your script would re-set these permissions to what you want. I see. 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. Another way would be to change the way in which your webapp my_webapp works. (And here I assume that these files are static files - like images or html files, but not JSP files). Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/, and leave it to Tomcat to serve those file when a browser requests them. Instead of that, you could have an active webapp my_webapp, which responds to browser requests for those files, and which actively reads them and returns them to the client. In such a case, the files would not need to be directly under ../webapps/my_webapp/, they could be anywhere, including in some separate directory (preferably even not under the top Tomcat directory), where your active webapp can find them. And that directory could have the permissions that you want, and Tomcat would never touch it. To be clean and flexible, the path to that directory could be in a parameter in your webapp's web.xml, which would be read by your active webapp, and that is where it would look for those files. I am sure that there are several cleverer ways to achieve the same result without having to do any real additional programming. For example by using a servlet filter inserted around your webapp, and which would do the real work (e.g. look up for UrlRewriteFilter in Google; it may well allow to do that kind of thing). You may even find a way to cleverly use some code to modify on-the-fly the location where Tomcat will look for the file (your appropriately permissive directory, where you moved the files), and then let Tomcat return it to the browser anyway. (That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. But I digress, this is a Tomcat list). I believe that another way (at least under Tomcat 7 (the current version), may be to use the aliases attribute in the Context descriptor of your application. See : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html to understand how Tomcat deploys an application, and where that Context descriptor would need to be. (Nite: you need to verify this, I have never used aliases under Tomcat and I do not really know if that would be usable here). The one solution which gives you the most control is the one where your own my_webapp webapp is the one which actually reads and returns the files to the browser, because that is your code, and you can bend it in any way you want. (Including for example, returning something nice to the client, when the file that he wants is not there). Another time maybe :). Be careful that changing the permissions of your webapps/my_webapp directory itself, may weaken the security of your Tomcat website, because there may be other things in there than the files which you intend to serve to the clients. That's why having these files somewhere else than directly under webapps/my_webapp may be preferable
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: Hello and thank you for your answer. On 2014-03-12 11:49 PM, Neven Cvetkovic [via Tomcat] wrote: How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Yes, well, how shall I do that? Personally, I don't think you should. The scary thing here is All newly created files. That means e.g. all webapps deployed by Tomcat, not just your my_webapp. But if you wanted to do it nevertheless, under Linux you would do that in the /etc/init.d script which starts Tomcat. Who is placing these files into the webapp folder? I am manually placing my_webapp.war in the Tomcat6 webapps folder. Best regards. -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On 2014-03-11 7:44 PM, André Warnier [via Tomcat] wrote: Maybe easier : supposing that your user-id is lmhelp1. Do adduser lmhelp1 tomcat6 (that will add your user-id to the group tomcat6). Then logout, and login again. Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. That may be enough for what you need to do. Hello, Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. (I'm not sure that I completely understand this sentence.) Yet, thank you for the advice about adding the user lmhelp1 to the group tomcat6. That's a good idea but tomcat6, as a the owner group of the files that are created, doesn't have the write permission by default on these files... I'm interested in ACLs but for now, I solved my problem by logging into the server as tomcat6 (via SSH). Best regards, -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: On 2014-03-11 7:44 PM, André Warnier [via Tomcat] wrote: Maybe easier : supposing that your user-id is lmhelp1. Do adduser lmhelp1 tomcat6 (that will add your user-id to the group tomcat6). Then logout, and login again. Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. That may be enough for what you need to do. Hello, Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. (I'm not sure that I completely understand this sentence.) Yet, thank you for the advice about adding the user lmhelp1 to the group tomcat6. That's a good idea but tomcat6, as a the owner group of the files that are created, doesn't have the write permission by default on these files... If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). To be able to delete a file, you need write permission to the directory where the file resides (and not necessarily to the file). Moving or deleting a file, is an operation which changes the content of the directory containing the file. It does not modify the file itself, so you do not need write permission to the file. So, since you have access to the code of the upload webapp, you can decide in which directory it writes the uploaded files. And since you have full control of the system, you can set the permissions of that upload directory as you wish them to be. So if you set the upload directory to belong to user tomcat6, and to have write permission for the group (tomcat6), and you add your own user-id to the group tomcat6, then you should be able, under your own login, to move and/or delete these files (independently of the permissions of the files themselves). I'm interested in ACLs but for now, I solved my problem by logging into the server as tomcat6 (via SSH). That is interesting, but it implies that you have modified the standard user tomcat6 in such a way that it now has a shell when it logs in. By default, this user would have been created with /bin/false as a shell entry (in /etc/passwd). That would prevent a shell login as that user, and it is a security feature. It normally prevents anyone who has managed to take control of your Tomcat server (though a malicious or buggy webapp e.g.), to easily obtain a shell and being able to execute any command on your server through such a shell. By changing this, you weaken the security of your system. In your particular case, it may not matter very much. But in the general case, that is not a good thing. Remember that a hacker which gains access to your server, cannot only do damage to your server. He can use your server as a platform to do damage to other servers, making it look like it is your server doing it. Example: your webapp allows users to upload files to your server. How does your webapp handle the file names, for the files that the user uploads ? Do you use the original filename that the user provides ? If yes, are you filtering this filename for characters that may have a meaning for a shell (like | or or or etc..) ? Regarding ACls : under Linux, the usage of setfacl and siblings is kind of a dark art, reserved to wizards of the 3rd level and up. I know relatively little about them, but one thing which I think that I remember, is that you must enable ACLs on the filesystem in which you want to use them, in the command that mounts that filesystem. Maybe that is what was missing in your case ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Hello and thank you for your answer. On 2014-03-12 11:54 AM, André Warnier wrote: If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them That's it. then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). Ok. In my case, the target directory is the webapp directory my_webapp. This directory is created when tomcat6 deploys the archive my_webapp.war which I put into the Tomcat webapps container. By default, the owner of this directory is tomcat6, the owner group is tomcat6 and the permissions are 755. So as you see, unfortunately, the owner group doesn't have the write permission :/ To be able to delete a file, you need write permission to the directory where the file resides (and not necessarily to the file). Moving or deleting a file, is an operation which changes the content of the directory containing the file. It does not modify the file itself, so you do not need write permission to the file. So, since you have access to the code of the upload webapp, you can decide in which directory it writes the uploaded files. And since you have full control of the system, you can set the permissions of that upload directory as you wish them to be. Yes indeed. There are no problems with the source directory. So if you set the upload directory to belong to user tomcat6, and to have write permission for the group (tomcat6), and you add your own user-id to the group tomcat6, then you should be able, under your own login, to move and/or delete these files (independently of the permissions of the files themselves). That would be perfect if we were not talking about the source directory but about the target directory... What I actually do is copy manually (using WinSCP and logged into WinSCP as user1) a file that was uploaded by the webapp into what you call the upload directory (source directory) into the webapp root directory namely my_webapp (target directory). (I hope this sentence is clear enough :)) As you suggested (and which is a good idea), I added my user id, say user1 to the group tomcat6. Yet I'm lacking the write permission for the owner group of the target directory (my_webapp). Maybe there is a way to tell the process which deployed the webapp (tomcat6, java?) to enable the write permission for the root directory of a deployed webapp and for its owner group ? I'm interested in ACLs but for now, I solved my problem by logging into the server as tomcat6 (via SSH). That is interesting, but it implies that you have modified the standard user tomcat6 in such a way that it now has a shell when it logs in. By default, this user would have been created with /bin/false as a shell entry (in /etc/passwd). That would prevent a shell login as that user, and it is a security feature. It normally prevents anyone who has managed to take control of your Tomcat server (though a malicious or buggy webapp e.g.), to easily obtain a shell and being able to execute any command on your server through such a shell. By changing this, you weaken the security of your system. In your particular case, it may not matter very much. But in the general case, that is not a good thing. Remember that a hacker which gains access to your server, cannot only do damage to your server. He can use your server as a platform to do damage to other servers, making it look like it is your server doing it. Example: your webapp allows users to upload files to your server. How does your webapp handle the file names, for the files that the user uploads ? Do you use the original filename that the user provides ? If yes, are you filtering this filename for characters that may have a meaning for a shell (like | or or or etc..) ? Ah ok. Indeed, I replaced /bin/false with /bin/bash in /etc/passwd for the user tomcat6. I just reverted this since you wisely advise and explain why not to do it :) Regarding ACls : under Linux, the usage of setfacl and siblings is kind of a dark art, reserved to wizards of the 3rd level and up. I know relatively little about them, but one thing which I think that I remember, is that you must enable ACLs on the filesystem in which you want to use them, in the command that mounts that filesystem. Maybe that is what was missing in your case? I actually went to /etc/fstab and added the option acl for the partition /home. So setfacl works for me. Thank you. Best regards, -- Léa Massiot - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: Hello and thank you for your answer. On 2014-03-12 11:54 AM, André Warnier wrote: If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them That's it. then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). Ok. In my case, the target directory is the webapp directory my_webapp. This directory is created when tomcat6 deploys the archive my_webapp.war which I put into the Tomcat webapps container. By default, the owner of this directory is tomcat6, the owner group is tomcat6 and the permissions are 755. So as you see, unfortunately, the owner group doesn't have the write permission :/ Ok, I understand : the target directory is not created by you, it is created by Tomcat, so Tomcat sets these permissions, and they do not fit what you want to be able to do. First, to my knowledge there is no standard way, by configuration alone, to tell Tomcat to set these permissions differently when it creates that directory as a result of the deployment of your webapp's war-file. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). One way of course, since Tomcat is Open Source, would be to find the place in Tomcat where it does this, modify that code, and build your own modified Tomcat. But that way is hard and full of accidents waiting to happen, so you probably don't want to do that. Another way would be to change the way in which you deploy your webapp, and that way itself subdivides into several sub-ways : 1) instead of deploying your webapp as a war-file (and let Tomcat explode it), you could already explode that webapp.war yourself, and deploy your application statically. That is, already create in advance the directory .../webapps/my_webapp, with the exploded contents of your war-file in it. You could then set the permissions of the my_webapp directory once and for all, and Tomcat would probably not re-set them. 2) you could use a script to deploy your war-file programmatically, using the Tomcat Manager application to do it. Tomcat would explode the war-file (creating the webapps/my_webapp dir in the process, with permissions 755); and then your script would re-set these permissions to what you want. 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. Another way would be to change the way in which your webapp my_webapp works. (And here I assume that these files are static files - like images or html files, but not JSP files). Currently, you (probably) just move the uploaded files somewhere under webapps/my_webapp/, and leave it to Tomcat to serve those file when a browser requests them. Instead of that, you could have an active webapp my_webapp, which responds to browser requests for those files, and which actively reads them and returns them to the client. In such a case, the files would not need to be directly under ../webapps/my_webapp/, they could be anywhere, including in some separate directory (preferably even not under the top Tomcat directory), where your active webapp can find them. And that directory could have the permissions that you want, and Tomcat would never touch it. To be clean and flexible, the path to that directory could be in a parameter in your webapp's web.xml, which would be read by your active webapp, and that is where it would look for those files. I am sure that there are several cleverer ways to achieve the same result without having to do any real additional programming. For example by using a servlet filter inserted around your webapp, and which would do the real work (e.g. look up for UrlRewriteFilter in Google; it may well allow to do that kind of thing). You may even find a way to cleverly use some code to modify on-the-fly the location where Tomcat will look for the file (your appropriately permissive directory, where you moved the files), and then let Tomcat return it to the browser anyway. (That's how I would do this, if we were talking about Apache httpd, instead of Tomcat. But I digress, this is a Tomcat list). I believe that another way (at least under Tomcat 7 (the current version), may be to use the aliases attribute in the Context descriptor of your application. See : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html and see : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html to understand how Tomcat deploys an application, and where that Context descriptor would need to be. (Nite: you need to verify
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
On Mar 12, 2014 11:31 PM, André Warnier a...@ice-sa.com wrote: Lmhelp1 wrote: Hello and thank you for your answer. On 2014-03-12 11:54 AM, André Warnier wrote: If all you need to do, is to 1) read those files, to look at them 2) if they are ok, move them somewhere else 3) if they are not ok, delete them That's it. then (under Linux) you do not need write permissions to the files themselves. To be able to read a file, you need : - read and browse (x) access to the directory where these files are, and any directory above that one, up to /. To be able to move a file from one directory to another, you need write permission to the source directory and the target directory (and not necessarily to the file). Ok. But there are probably a dozen ways to do this anyway (and I don't know enough to think of all of them). 3) there are probably a couple more ways to do essentially the same, which I do not know and will leave it to someone else more qualified to suggest. How about setting up umask 002 on tomcat6 user? All newly created files would be have 775 permission. Who is placing these files into the webapp folder?
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 3/11/14, 12:31 PM, Lmhelp1 wrote: -- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. You can set the file permissions (bits) by setting the umask of the process. When creating files, the process uid and gid are used as defaults for ownership. If you want to use user1 and group1, then you should run Tomcat under those uid and gid settings. I'm unaware of any setting which will allow a process to run under one uid but files created by that process are owned by another user. You might be able to get away with a cron process that re-assigns ownership of the files periodically. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTH0RgAAoJEBzwKT+lPKRYehAQAIYB0YNPWaB0vqjjlDS42adl KCmU6dj3CnGfw4I+4b4yLymAdixrv1Y0tuLGvXwWIznUZChhGaL2tVYTacuzO2yt mwipWy5OIBKchFCxjlL0SsSEfx3OFQ7sbDQuxwHW9wpq1MkqnNXWtv0VhKi7Q9cf A6JAyJIs4lOHO79KDtYRU+ckB3lT0CynlQGR0xKevdF6CaLE8EHYsAV8YMJhM07p kPdH1W3UXS6ta3QGybDbVe2ED5WuuWoCJoitavJgocNaOjBkoNzOv8Fyrfn0pvFQ m6A0Rm+W5apt2kseb1o63COlka8/jV7Bx8BxEiQEzZ29apGb5tc7tflI6c3n6e/H Hgy4YrZpUrWkH6Aa4NCwyiqzFgcsob1uFBTACnR5+imXiEYX9acqJtJSmc2qdcbF Ye7OFxyncsH3wvcXwXabJjqakBqFZ85BMizZ4XKRptnOvXOh5rr4K03LdDyqXExn ufrLvCGWIb1lofhCbqbCK0OQp68minoiEmyi98n9S+9vwfvonG5cUdPNmBpLu2r4 DTEnPnI6w75nvxv7ATdTKFq7AgR0ftJvwqunazFaODLPgadP57q4FEqI38yglrIK KKBd4xF8HmeV1D+Viqo2OD9NKZX24llFQwVT7v4vXMf+/1SJgnw1uqZJhSCDnVsM STJCNdoHG2z32H/hgb7z =gIgR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: -- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. It sounds like you have installed Tomcat 6, using the standard Ubuntu/Debian tomcat package (apt-get etc..). That package is the one that specifies the user/group under which this Tomcat is running (in reality it is the java JVM which is running, and the JVM runs Tomcat and webapp code). Since the JVM is started under the user/group tomcat6, when the webapp creates a file, it uses that user/group, and the umask of that user, to set the file ownership and permissions. To change this, you would have to change the user-id/group under which Tomcat is started (in /etc/init.d/tomcat6). However, the Debian Tomcat package creates a lot of files in different places in the filesystem, each with user/group tomcat6, and corresponding permissions. So it is going to be a lot of work to change all that and still have your Tomcat running properly. It would probably be better, and less work in the end, to remove this packaged tomcat, and install a real tomcat, from the Tomcat website. Then you can specify a user-id under which to run, without getting in trouble with all the pre-installed files all over the place. There may be other options (such as using ACLs on the directory where the files are created), but they are quite difficult to recommend without having access to your server. The other thing is : do you have the code of that webapp and could you change it ? And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Thank you for your answers. It sounds like you have installed Tomcat 6, using the standard Ubuntu/Debian tomcat package (apt-get etc..). Yes indeed. That package is the one that specifies the user/group under which this Tomcat is running (in reality it is the java JVM which is running, and the JVM runs Tomcat and webapp code). Since the JVM is started under the user/group tomcat6, when the webapp creates a file, it uses that user/group, and the umask of that user, to set the file ownership and permissions. Yes, it looks like this is it. To change this, you would have to change the user-id/group under which Tomcat is started (in /etc/init.d/tomcat6). However, the Debian Tomcat package creates a lot of files in different places in the filesystem, each with user/group tomcat6, and corresponding permissions. So it is going to be a lot of work to change all that and still have your Tomcat running properly. All right, I won't do this then. It would probably be better, and less work in the end, to remove this packaged tomcat, and install a real tomcat, from the Tomcat website. Then you can specify a user-id under which to run, without getting in trouble with all the pre-installed files all over the place. Thank you, I understand. But I'm not going to do this either. There may be other options (such as using ACLs on the directory where the files are created), but they are quite difficult to recommend without having access to your server. I do have full access to the server... I'm interested in this solution but I couldn't find a way to force the file owner, owner group and permissions for a given directory using setfacl. I know this forum is not about ACLs but can you assist me on doing this? The other thing is : do you have the code of that webapp and could you change it ? Yes, I can. And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? The other process is me :) The webapp stores files in a directory. I, as a human, check these files. And when I'm ready, I put them manually in another directory (in the WebContent directory of the webapp to be more precise). I just do not want to put the files directly online. Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. Yes, well, if I log in as tomcat6, it will work. Best regards, -- Léa On 2014-03-11 6:16 PM, André Warnier wrote: Lmhelp1 wrote: -- Files created by a Tomcat webapp and owner, owner group, permissions for this file -- Hello and thank you for reading my post. I am running a Tomcat v6.0 webapp on a Debian 7.2 Wheezy OS. In particular, this webapp creates some files on the filesystem. The files created have: - tomcat6 as the owner user, - tomcat6 as the owner group, - 644 as the permissions granted to the owner, the owner group and others respectively. Is it possible to change this behavior? What I like to do is: - set the owner user to user1, - set the owner group to group1, - set the permissions to 660 for every new file created. It sounds like you have installed Tomcat 6, using the standard Ubuntu/Debian tomcat package (apt-get etc..). That package is the one that specifies the user/group under which this Tomcat is running (in reality it is the java JVM which is running, and the JVM runs Tomcat and webapp code). Since the JVM is started under the user/group tomcat6, when the webapp creates a file, it uses that user/group, and the umask of that user, to set the file ownership and permissions. To change this, you would have to change the user-id/group under which Tomcat is started (in /etc/init.d/tomcat6). However, the Debian Tomcat package creates a lot of files in different places in the filesystem, each with user/group tomcat6, and corresponding permissions. So it is going to be a lot of work to change all that and still have your Tomcat running properly. It would probably be better, and less work in the end, to remove this packaged tomcat, and install a real tomcat, from the Tomcat website. Then you can specify a user-id under which to run, without getting in trouble with all the pre-installed files all over the place. There may be other options (such as using ACLs on the directory where the files are created), but they are quite difficult to recommend without having access to your server. The other thing is : do you have the code of that webapp and could you change it ? And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Lmhelp1 wrote: ... The other thing is : do you have the code of that webapp and could you change it ? Yes, I can. And why do the files have to be owned by user1/group1 ? Is it because some other process must be able to read/write them ? The other process is me :) The webapp stores files in a directory. I, as a human, check these files. And when I'm ready, I put them manually in another directory (in the WebContent directory of the webapp to be more precise). I just do not want to put the files directly online. Can you not give to this other process the permissions to read/write the files of tomcat6/tomcat6 ? That may be easier to achieve. Yes, well, if I log in as tomcat6, it will work. Maybe easier : supposing that your user-id is lmhelp1. Do adduser lmhelp1 tomcat6 (that will add your user-id to the group tomcat6). Then logout, and login again. Then you would already have the permissions to read/write any file that has the appropriate permissions to allow this for the group tomcat6. That may be enough for what you need to do. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
