Edgewall Software
Modify

Opened 8 years ago

Closed 8 years ago

#8152 closed defect (fixed)

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

Reported by: bavison@… Owned by: Remy Blank
Priority: normal Milestone: 0.11.5
Component: web frontend/tracd Version: 0.11.3
Severity: normal Keywords: python24
Cc:
Release Notes:
API Changes:

Description

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

Attachments (0)

Change History (8)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by 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?

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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).

comment:5 Changed 8 years ago by Christian Boos

Keywords: python24 added
Milestone: 0.11.5

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?

comment:6 Changed 8 years ago by Ben Avison <bavison@…>

Yes, we're using python 2.4.

comment:7 in reply to:  5 Changed 8 years ago by Remy Blank

Owner: set to 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.

comment:8 Changed 8 years ago by Remy Blank

Resolution: fixed
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Remy Blank.
The resolution will be deleted.
to The owner will be changed from Remy Blank to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.