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 secure or not, if users have to login, if one user can
overwrite documents uploaded by another user, if they name their uploaded files themselves
(sometimes with filenames which could contain "bizarre" characters), and so on.
Nor do we know if this concerns 3 files, or 300, or 3000, or 30000..
An application which allows users to upload files or website pages themselves and share
them, is something that appears deceptively simple at first, but is in reality quite a
complex and delicate thing to create, if it has to be safe, reliable, portable, scaleable,
maintainable etc.
If a "quick fix" like described above meets all your needs (and your time and budget),
then fine. You should not over-complicate things if it is not necessary.
Otherwise, you may want to have a look at existing applications (many of them free and
open-source) which may already do all these things, and at the same time resolve (or even
just describe) issues of which you probably have not even thought of yet.
But this is all not really our business. Your original question was about how to change
the permissions of files created by a Tomcat webapp, and you have been provided with
several ways of doing this (or not doing it), each with its own advantages/inconvenients.
I hope that helped, and the rest is up to you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
