Skip to content

Check for unprotected datadir stopped working in oC 10 #28344

Closed
Closed
Check for unprotected datadir stopped working in oC 10#28344
Labels
Type:Bugneeds inforegressionsev3-medium

Description

@ghost
ghost
opened on Jul 8, 2017

Not filling out the issue template as i could reproduce this reliable on demo.owncloud.org with a complete different setup then mine.

While doing #28343 i've noticed that ownCloud 10 seems to not warn about an unprotected data dir anymore:

  1. Open https://demo.owncloud.org/index.php/settings/admin?sectionid=general
  2. Login with: admin:admin
  3. See only "Transactional file locking should be configured to use memory-based locking, not the default slow database-based locking"
  4. Do a curl -i https://demo.owncloud.org/data/owncloud.log
  5. See that the data dir is unprotected

The response to https://demo.owncloud.org/index.php/settings/ajax/checksetup is something like the below. Seems ownCloud thinks that the protection is working where it is indeed not working.

serverHasInternetConnection	true
isMemcacheConfigured	true
memcacheDocs	"https://doc.owncloud.org/serv…/go.php?to=admin-performance"
isUrandomAvailable	true
securityDocs	"https://doc.owncloud.org/serv…0.0/go.php?to=admin-security"
isUsedTlsLibOutdated	""
phpSupported	Object
eol	false
version	"7.0.15-0ubuntu0.16.04.4"
forwardedForHeadersWorking	true
reverseProxyDocs	"https://doc.owncloud.org/serv…o.php?to=admin-reverse-proxy"
isCorrectMemcachedPHPModuleInstalled	true
hasPassedCodeIntegrityCheck	true
codeIntegrityCheckerDocumentation	"https://doc.owncloud.org/serv….php?to=admin-code-integrity"

cc @PVince81 @Peter-Prochaska

Activity

  2. ghost changed the title [-]Check for unprotected datadir stopped working in oC 10?[/-] [+]Check for unprotected datadir stopped working in oC 10[/+] on Jul 8, 2017
  3. PVince81
    added
    Type:Bug
    regression
    sev3-medium
    on Jul 10, 2017
  4. PVince81
    added this to the triage milestone on Jul 10, 2017

  5. PVince81 commented on Jul 10, 2017

    @PVince81
    PVince81
    on Jul 10, 2017
    Contributor

    @kdslkdsaldsal not sure why the JS test would stop working, need to investigate

  6. PVince81 commented on Aug 18, 2017

    @PVince81
    PVince81
    on Aug 18, 2017
    Contributor

    @kdslkdsaldsal works for me with 10.0.3beta:

    1. Setup OC on Apache
    2. Do not configure Apache as per the docs, which usually adds a block with AllowOveride and others
    3. Go to admin page

    I see this: Your data directory and your files are probably accessible from the Internet. The .htaccess file is not working. We strongly suggest that you configure your web server in a way that the data directory is no longer accessible or you move the data directory outside the web server document root.

    Maybe you discovered a slightly different setup where the ajax request to the test file doesn't go through despite the server being unprotected ?

    If it still happens, can you check the network call to "htaccesstest.txt" ?
    Maybe the sever failed to generate this file before opening the admin page ?

  7. PVince81
    added
    needs info
    on Aug 18, 2017

  9. PVince81 commented on Aug 21, 2017

    @PVince81
    PVince81
    on Aug 21, 2017
    Contributor

    @kdslkdsaldsal no worries. So this either tells us that the bug exists in 10.0.2 and is fixed in 10.0.3beta, or the bug still exists but there is a difference in the env.

    Let's try it with the UCS appliance

  10. PVince81 commented on Aug 21, 2017

    @PVince81
    PVince81
    on Aug 21, 2017
    Contributor

    Had a quick try locally with the release tarball 10.0.2 and I do see the warning appear.

  11. PVince81 commented on Aug 21, 2017

    @PVince81
    PVince81
    on Aug 21, 2017
    Contributor

    I was told that both the demo instance and this appliance have their data folder in a separate folder. So maybe there's a bug in the data folder check that shows false positives when data folder is outside.

  12. michaelstingl commented on Aug 21, 2017

    @michaelstingl
    michaelstingl
    on Aug 21, 2017

    There is a orphaned data dir in Docker and Appliance. The configured data dir is another one. I guess the check only works on the configured one, not on the orphaned default one.

  13. ownclouders
    added
    status/STALE
    on Nov 16, 2017

  14. ownclouders commented on Dec 13, 2017

    @ownclouders
    ownclouders
    on Dec 13, 2017
    Contributor

    Hey, this issue has been closed because the label needs info is set and there were no updates for 14 days. Feel free to reopen this issue if you deem it appropriate.

  15. ownclouders
    closed this as completedon Dec 13, 2017
  16. ownclouders
    removed
    status/STALE
    on Dec 13, 2017
  18. felixboehm
    removed this from the triage milestone on Apr 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type:Bugneeds inforegressionsev3-medium

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions