You are here: Foswiki>Tasks Web>Item11148 (13 Oct 2011, GeorgeClark)Edit Attach

Item11148: Running with sticky bits breaks umask calculations.

Priority: Urgent
Current State: Closed
Released In: 1.2.0
Target Release: minor
Applies To: Engine
Component: Configure
Reported By: PaulHarvey
Waiting For:
Last Change By: GeorgeClark
Running with sticky group on directories, because we don't like re-chown/chmod'ing all the time when messing with data & pub in our development environment, leads to this error:

Error: The system umask (002) is not compatible with the configured directory and file permissions. A umask of 1777777777777777776002 is required to support the configured Directory and File masks of 2775 and 2664. Enable this setting to have the Foswiki override the umask to be compatible with your configured permissions.

-- PaulHarvey - 27 Sep 2011

In addition, settings on {dirPermission} and {filePermissions} should default to 0700 / 600 and not 0775 / 644, for security reasons. Otherwise anybody with shell access can read all foswiki data no matter which other access rights are enforced using foswiki ACLs. It would be nice to have a button "fix dir and file perms right now". This is fatal in single sign on environments.

-- MichaelDaum - 27 Sep 2011

Is this really urgent? Have we ever shipped with a default of 0700?

It's worth noting that the "out-of-the-box" Foswiki is completely open. For example on trunk, our default ACLs mean that new AJAX CommentPlugin allows WikiGuest spam if you remove /bin/rest from {AuthScripts} Item9639.

See also SecurityChecklists

I don't think this should block 1.1.4

-- PaulHarvey - 27 Sep 2011

Better secure out of the box than the opposite, even for wikis.

-- MichaelDaum - 27 Sep 2011

Kenneth, your opinion? IIRC you were very adamant about group readable topics for many environments. You wanted sites to work by default. I know that on apache sites using suexec, group readable is required because the web server runs under a different user/group than the cgi scripts.

-- GeorgeClark - 27 Sep 2011

Un-hijacking this task. Deciding to change default permissions is a philosophical / religious discussion and involves every MANIFEST file, BuildContrib, and will block fixing a real bug. (Not that problems with default permissions are not real but ... ) Changing code to AND the entered file and directory permissions with 777 to prevent them from breaking the umask calculation.

Note that the umask checker is not part of 1.1.4, it's trunk only. Also since it's new to trunk, we don't need to document this.

Paul, see if this works for you. Seems okay here.

-- GeorgeClark - 27 Sep 2011

FWIW, the off-line tasks framework (yes, it exists, just needs user doc & port to the new configure) includes a utility that knows how to read MANIFESTs and apply machine, site, release or default security policy to listed files and directories. It allows one to specify a mapping between the MANIFEST protections and those to be applied, and it also deals with SeLinux in a similar way.

It would not be hard to generalize for the whole release. I think this is a better approach than trying to agree on a default. We can't get a default right - there are too many philosophies - not to mention corporate standards and auditors. Better to provide a tool.

As I've noted before, the big problem with the current scheme is that every install (even of a plugin), update or patch imposes the default permission scheme. The utility/mapping file approach will fix that - once a policy is specified, the utility - and eventually all the kit installers & configure - will obey it.

Back to the original issue - sticky bits breaks umask. That's not all it breaks. The checkers in configure's General Path Settings claim to stop after checking 5000 errors in my (trivial, no user topics) Foswiki trunk. I haven't investigated in detail, but they seem confused by the sticky group bit - so ANDing with 0777 needs to happen for those checks too.

-- TimotheLitt - 27 Sep 2011

Hm. The checkers stop after checking 5000 files - not 5000 errors. The check does take quite a bit of time, and the limit was put in place to prevent really excessive times during config startup for sites with a large number of webs and files. This really needs to be moved into a Check / Fix button. Now that I've written the routine to send test email, it probably wouldn't be too hard to do this. But that's for another time...

As far as the file and directory checks and sticky bits, I've tested setting the defaults to 2644 and 2755, and it seems to correctly flag directories that have too much or too little permission. If you want the default to be 2755 - group sticky bit - on directories, the checker should point out any that have it missing, or have too much permission, such as User sticky. Works for me here anyway.

Please provide an example of the settings of {RCS}{dirPermission}, {RCS}{filePermission}, and the chmod of a file and/or directory that is incorrectly reported so I can recreate and fix.

-- GeorgeClark - 27 Sep 2011

I tried to add an attachment ( a .png screen grab of 260KB) with an example @ 21:32 UTC, but I'm getting:

Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.


-- TimotheLitt - 27 Sep 2011

The server is set for a maximum attachment size of 100000, and fcgi has a max request size of 131000. The message in the log was mod_fcgid: HTTP request length 131400 (so far) exceeds MaxRequestLen (131072)

-- GeorgeClark - 28 Sep 2011

Thanks for the fix George, tested as works-for-me-now smile

-- PaulHarvey - 28 Sep 2011

Thanks for fixing the server - would have been nice to get a useful error from the upload attempt.

Meantime, I spent some time (more than I intended :-() investigating, so I won't do the upload after all.

I had "directory 2755 exceeds requested 0755" errors. I don't think of sticky group as "greater" than non-sticky (it's orthogonal to permission level), so this confused me. Perhaps "exceeds"/"insufficient" should be restricted to mask & 0777, and "differs from requested" should be for the 07000 bits? Or maybe it's just me... Anyhow, that was enough to cause me to ignore the checker output the first time(s) around.

I changed the Store parameter to add 2000 bit (should the "verify the store expert settings" message have a hyperlink to the settings? If a standard checker sends a user there, should they be "expert"?)

Fixed the valid complaints.

Still have (this is running from svn/trunk):

Did an svn update to collect the checkin for the sign-extension error. And of course this produced errors on updated files in pub and data - just as an install/normal update would. It would be good if some of you lived with non-default permissions so the pain was shared smile

That left me with some "errors" that I'm not happy about. But I think that's the "policy" discussion...for another topic. Along those lines, I just uploaded a newer snapshot of the task framework's post-installer that I mentioned earlier to the SecurityChecklists topic. That's my stab at a starting point for fixing the bigger problem.

-- TimotheLitt - 28 Sep 2011

  • Re: Server error during upload. Not fixed. Not sure if there is an easy fix. fcgi kills the request before Foswiki can get notice that the uploaded file is too big. We could allow fcgi to have a larger MaxRequestLen but I'm not sure how big to make it. It would allow the upload to complete so that Foswiki could then reject the attachment based upon size with a more meaningful message. We are (I am?) still tuning and learning the impact of fcgi. Probably should have a separate task.

  • Re: Wording of insufficient / excessive vs. "differs from"... This is really a corner case. I hope that anyone digging into expert settings can deal with it. How about more generic "Differs from expected permissions. Check for excess or insufficient permission". I'll look at it. I don't think it's worth masking off the sticky bits and treating them with different error messages.

  • Re: Missing WebPreferences Topic TestCases is an exception to the rules and has some webs or non-webs without the topic. A normal installation won't have these installed. IMHO another corner case that is not worth fixing. But needs a separate task if we need to fix it.

If there is any chance that you can use IRC, some of this stuff is easier to discuss there. And definitely loading up multiple issues into a single task causes them to be missed. It's much more helpful to everyone to create a task per issue so that issues don't get lost in the noise.

-- GeorgeClark - 28 Sep 2011

On the 0700 vs 0755 and 0644 vs 0600 history

We tried this many years ago in the old project and it created a hell of problems for those that do not have root access to the server.

Shared hosts and wiki admins in orgs that has separate admins for the Unix/Linux with psyco mentality cannot chown files. We need to learn from our mistakes and remember what we learned.

Looking at the consequence of the less tight default. Unless the server is a multipurpose machine where none-priviledged users have logins, the attack access will mainly be via the webserver. And the webserver has access. It must have full access if the rights are 0700. We have the right access rights that ensures that all can get started and then it is a few chown commands as root that is required to tighten more. And as George said... It is not really what the bug report was about anyway.

-- KennethLavrsen - 05 Oct 2011

Closing this - fixed on trunk. Doesn't impact any released code.

-- GeorgeClark - 13 Oct 2011

ItemTemplate edit

Summary Running with sticky bits breaks umask calculations.
ReportedBy PaulHarvey
Codebase trunk
SVN Range
AppliesTo Engine
Component Configure
Priority Urgent
CurrentState Closed
Checkins distro:0e5d3003f759 distro:da7b21c7b980
TargetRelease minor
ReleasedIn 1.2.0
Topic revision: r17 - 13 Oct 2011, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy