[TriLUG] Odd Tomcat (or shell-scripting?) problem - regular user process creates root-owned files
jason at oldos.org
Tue May 29 11:44:17 EDT 2007
I *know* that on Debian, this is caused by a kernel bug. It's actually
the reason that Zimbra doesn't have a supported version on Debian.
On 5/29/07, Jeremy Portzer <jeremyp at pobox.com> wrote:
> Hey folks,
> I'm encountering a strange problem related to file permissions with
> Tomcat, the Java application server. Tomcat includes a procedure to
> auto-rotate its logfiles, but when it does so, new log files are created
> with root ownership, even though the java process runs as a normal user.
> I'm trying to understand how this can be.
> In the init scripts we use to start Tomcat, which are run as root, the
> following is executed:
> su - $tomcatuser -c "$BASEDIR/tomcat-startup.sh internal_start"
> (this tomcat-startup.sh then goes through a number of other steps and
> eventually launches a JVM, which runs the actual Tomcat application code.)
> It is easy to confirm that this command is indeed executed, the "su"
> command is executed, and the process is listed as running as the regular
> user ("bbuser") in the "ps" listing. I have done this by putting 'echo'
> commands in various places throughout the shell scripts to make sure the
> flow control is moving exactly as I expect it.
> The log files are all created by the Tomcat java application (not any of
> the shell scripts), and are in a directory with normal setup as follows:
> $ ls -ld tomcat/logs
> drwxr-xr-x 3 bbuser bbuser 4096 May 29 01:24 tomcat/logs
> BUT, some log files nevertheless appear with root ownership after
> starting the process, such as:
> -rw-r--r-- 1 root root 0 May 29 01:24
> These will continue to appear for each day, e.g. catalina.2007-05-30.log
> will exist the next day (even if Tomcat isn't restarted). This seems to
> rule out a mistake in my troubleshooting of the shell scripts.
> Interestingly, Tomcat's standard output is then filled with Permission
> Denied errors as it can't write to these files - since bbuser doesn't
> have write permission - but yet it was the very process that
> (apparently) created the files !?!
> The Tomcat logger appears to be configured correctly (according to the
> defaults for Tomcat 5.5.17, the version in use).
> I realize this may be better directed at a Tomcat list, but I'm still
> trying to understand the fundamental action from a Linux perspective...
> what are the situations in which this could happen? The info page of
> "su" states that it "runs a command ... with the real and effective user
> id, group id, and supplemental groups of a given USER." How then, can
> the java process, regardless of any bugs that may or may not exist
> within Tomcat, EVER create a file with root ownership?
> Some other sanity-checking:
> The user in this case is a perfectly normal user with its own group.
> From /etc/passwd:
> And "id" confirms there's nothing else odd with the group setup:
> [bbuser at bbhost bbuser]$ id bbuser
> uid=550(bbuser) gid=550(bbuser) groups=550(bbuser)
> My test system is Red Hat Enterprise Linux 4.0 with Java JDK 1.5.0_04
> but the problem is seen across a range of Linux and Java versions (and
> possibly even on Solaris/sparc). The identical problem has also been
> reported on another email list here, without resolution:
> Any further troubleshooting tips would be appreciated. Again, I just
> don't understand how a regular user process could EVER create a
> root-owned file, regardless of any bugs that may exist within Tomcat (or
> the JDK for that matter).
> Jeremy Portzer
> jeremyp at pobox.com
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
More information about the TriLUG