tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Files created by a Tomcat webapp and owner, owner group, permissions for this file
Date Wed, 12 Mar 2014 10:54:48 GMT
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:
For additional commands, e-mail:

View raw message