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: users-h...@tomcat.apache.org
