Can't upload attachments to wiki pages or tickets using tracd --daemonize

[bavison@…]

This bug manifests itself like this:

Trac detected an internal error:
OSError: [Errno 13] Permission denied: '/path/to/project/attachments/wiki/Page/file'

when attempting to upload the first attachment to a wiki page or ticket.

It only happens when using tracd, and then only if the —daemonize switch is used. If exactly the same command line is used without —daemonize (and —pidfile) then it works correctly. I have reproduced this with tracd using both HTTP and AJP protocols.

What appears to be happening is that tracd creates a subdirectory of project/attachments/wiki or project/attachments/ticket to hold all the attachments for that wiki page or ticket. However, it creates the subdirectory with permissions 662 (rw-rw—w-) and thereby denies itself access to the contents of the subdirectory (which requires execute permissions).

This can be worked around by manually chmodding the subdirectory, but this is impractical on an ongoing basis since it needs executing for every wiki page or ticket that needs attachments. Note that once this is done, the files tracd creates within the subdirectory also have permission 662.

When tracd is run without —daemonize, the subdirectory permissions are 775, which is OK.

Tested on:
RHEL and CentOS 5.2
trac 0.11.3
sqlite 3.3.6

[Christian Boos]

—umask issue?

If you keep the default umask (022), the attachment directories should be created with 0777 & 0022 permissions, i.e. 0755, which should be fine.

But from your description, it doesn't look like you're specifying the umask yourself, is that correct? Try setting it or changing it to see if it has an effect.

[anonymous]

Actually I was specifying —umask=077. After some more experimenting, I can report:

• tracd without —daemonize gives directories with permissions 0775 (which is what I'd expect since the parent environment has umask 0002)
• tracd —daemonize without —umask gives directories with permissions 0755 (as you say, the default umask for a tracd daemon is 0022)
• tracd —daemonize —umask=077 gives directories with permissions 0662
• tracd —daemonize —umask=022 gives directories with permissions 0640

Have I misunderstood the syntax of —umask?

[anonymous]

I notice NOT(0662) = 0115 = decimal 77

Presumably not a coincidence? Is trac interpreting the argument to —umask as decimal despite the leading 0?

But then, NOT(0640) = 0137 = decimal 95, rather than 22.

[bavison@…]

Sorry, correction: tracd —daemonize —umask=022 gives directories with permissions 0751 (the files inside are 0640 = 0751 AND 0666). NOT(0751) = 0026 = decimal 22.

So it looks like it's just that —umask takes a decimal parameter even if prefixed with 0 as you'd normally expect for octal (which is the natural base for unix file permissions).

[Christian Boos]

You must be using Python 2.4, right? (​PythonBug:870807)

We should follow-up on r7358 to cope with pre-2.5 behavior. I guess we have no choice but turning the option type to a string and do the conversion ourselves. What do you think, Remy?

[Ben Avison <bavison@…>]

Yes, we're using python 2.4.

[Remy Blank]

Replying to cboos:

We should follow-up on r7358 to cope with pre-2.5 behavior. I guess we have no choice but turning the option type to a string and do the conversion ourselves. What do you think, Remy?

Yes indeed. I'm surprised that optparse didn't support non-decimal values in 2.4, as it is as simple as changing an int(str_value) to int(str_value, 0).

I'll take care of that as soon as 0.11.4 is out.

[Remy Blank]

Fixed in [8119]. The parameter is now always interpreted as octal, even without leading 0.