aspose file tools*
The moose likes Tomcat and the fly likes Control of file/directory chmod and chown when copying in a .war file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Control of file/directory chmod and chown when copying in a .war file" Watch "Control of file/directory chmod and chown when copying in a .war file" New topic
Author

Control of file/directory chmod and chown when copying in a .war file

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

I'm running Tomcat6 on Debian.

When I copy a .war file into the tomcat "webapps" directory, then tomcat will automatically explode the contents of the war and deploy the app. This part works perfectly.

But I want to control the file/directory ownership and chmod value. When tomcat expands the war file, the new directory is owned by "tomcat6:tomcat6"
and the protections are 754

I want to have it be owned by tomcat6:pat with 774

I don't know if this can be controlled by a Tomcat config parameter or some umask magic on the directories.

Any help, tips, pointers greatly appreciated.
Thanks
Pat
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

Actually, it would be more appropriate to add "pat" to the "tomcat" definition in /etc/group. This can be done either via brute-force text editing or one of the user-account maintenance utility programs.


Customer surveys are for companies who didn't pay proper attention to begin with.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

Tim Holloway wrote:Actually, it would be more appropriate to add "pat" to the "tomcat" definition in /etc/group. This can be done either via brute-force text editing or one of the user-account maintenance utility programs.

I can see that as an easy way to make "pat" be groupish, but it doesn't solve the file/directory protection issue. I need members of the tomcat6 group, not just the tomcat6 user itself, to be able to write the files.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

Pat Farrell wrote:
Tim Holloway wrote:Actually, it would be more appropriate to add "pat" to the "tomcat" definition in /etc/group. This can be done either via brute-force text editing or one of the user-account maintenance utility programs.

I can see that as an easy way to make "pat" be groupish, but it doesn't solve the file/directory protection issue. I need members of the tomcat6 group, not just the tomcat6 user itself, to be able to write the files.


That part should be controlled by umask, I believe.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

Tim Holloway wrote:That part should be controlled by umask, I believe.

I have never understood umask
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

Actually, I'm not quite correct. If you set the TOMCAT_HOME/webapps directory's mask (chmod) to "770", for example, the user "tomcat" can read, write, and list the (sub)directories. umask would actually be a limitation on top of that. So if TOMCAT_HOME/webapps had a mask of "750", for example, members of the tomcat group could read the WARs but not write them.

This is, of course, disregarding selinux, which is a whole 'nother bucket of worms.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

Tim Holloway wrote:Actually, I'm not quite correct. If you set the TOMCAT_HOME/webapps directory's mask (chmod) to "770", for example, the user "tomcat" can read, write, and list the (sub)directories. umask would actually be a limitation on top of that. So if TOMCAT_HOME/webapps had a mask of "750", for example, members of the tomcat group could read the WARs but not write them.


Except that it appears that tomcat deletes the old directory, creates a new one and then populates it. This loses the old protection, say 770 or 774
in addition to losing the old ownership.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

Pat Farrell wrote:
Tim Holloway wrote:Actually, I'm not quite correct. If you set the TOMCAT_HOME/webapps directory's mask (chmod) to "770", for example, the user "tomcat" can read, write, and list the (sub)directories. umask would actually be a limitation on top of that. So if TOMCAT_HOME/webapps had a mask of "750", for example, members of the tomcat group could read the WARs but not write them.


Except that it appears that tomcat deletes the old directory, creates a new one and then populates it. This loses the old protection, say 770 or 774
in addition to losing the old ownership.


That does not make sense. The default means of deployment in Tomcat is to copy files to TOMCAT_HOME/webapps. If Tomcat destroyed that directory, it would destroy previously-deployed apps, which would not only be very rude, but entirely different behavior from what I've seen for the better part of the last decade.

The other possibility - Tomcat altering the access rights - I also cannot swallow. Until VERY recently, Java had no ability to set or change file access rights, because there was no OS-independent scheme available to do so. And I think I would have noticed something like that in the Tomcat launcher script, which would have been the only other place where such things could happen.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

Tim Holloway wrote:That does not make sense. The default means of deployment in Tomcat is to copy files to TOMCAT_HOME/webapps. If Tomcat destroyed that directory, it would destroy previously-deployed apps, which would not only be very rude, but entirely different behavior from what I've seen for the better part of the last decade.


Sorry, I was sloppy in my wording.

Say my war is "patapi.war" and I put it in the TOMCAT_HOME/webapps directory.
Tomcat will then notice the new file and explode it into a patapi directory, specifically

TOMCAT_HOME/webapps/patapi

This directory is the one I am concerned about. It is TOMCAT_HOME/webapps/patapi that I want to write into, and that has bad ownership and protection when its created.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

OK, for that one, umask should be what it takes.

Although the default umask on my account is 0002, which means that only non-owner, non-group writes are forbidden.

If you can't get umask to do what you want, consider setting up a separate deployment script that explodes and chmods the WAR yourself.

Technically, a WAR is always ZIPed, and read-only, but, of course, in reality, changing a WAR on the fly is fairly common. The trickiest part is remembering to reflect those changes back to the application source once you've got the right setup.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

Tim Holloway wrote:
Although the default umask on my account is 0002, which means that only non-owner, non-group writes are forbidden.

Technically, a WAR is always ZIPed, and read-only, but, of course, in reality, changing a WAR on the fly is fairly common. The trickiest part is remembering to reflect those changes back to the application source once you've got the right setup.


That is what I want.
One of my problems with umask is which "account" is it for? Is it the login account? the documentation calls it an "environment variable" which would go in .bash_profile or /etc/profile
but there is no user directory for tomcat6.

Yeah, I'm not worried about the whole source control part for this stage. The reason I installed this instance of Tomcat is so the design folks can see how there layout and CSS changes look, without having to get them setup with Netbeans, Glassfish, the DBMS, etc.


Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

The umask applies to the currently-executing shell process. It is not independent or static, it literally is part or the shell environment.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4639
    
    5

Tim Holloway wrote:The umask applies to the currently-executing shell process. It is not independent or static, it literally is part or the shell environment.

So I should be able to put it in the /etc/init.d/tomcat script and have it be used?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

Pat Farrell wrote:
Tim Holloway wrote:The umask applies to the currently-executing shell process. It is not independent or static, it literally is part or the shell environment.

So I should be able to put it in the /etc/init.d/tomcat script and have it be used?

Probably. Certainly you could hack the catalina.sh script in a pinch.

But since umask adds restrictions, not removes them, you should check to see if something is already in the pipeline, and if so, where. Otherwise your attempt will have no effect.

Overall, though, I'd recommend creating a separate deployment process that cleans out the old WAR and its exploded counterpart, explodes the new WAR into TOMCAT_HOME/webapps, and then does a "chmod --recursive" on that exploded WAR. That way you can get what you want, stick to stock Tomcat, and not have to worry about hidden "gotchas".
 
 
subject: Control of file/directory chmod and chown when copying in a .war file
 
Similar Threads
Install Tomcat 6?
Error with Eclipse Galileo+Tomcat plugin
Converting Tomcat app from Windows to Ubuntu
JSF 1.1 and Tomcat 6
unable to deploy war file on tomcat5.5 (JVM 1.5.0)