Aegir manages secure permissions on modules, themes, libraries and files directories, so web sever has write access only to the files directory.

Now, when more people are using Drupal 7, more and more people will expect that the built-in plugin manager will just work.

While it is not the best practice, we should make it possible, otherwise some cool stuff (from the end user experience point of view) like one-click App (feature) install introduced by Open Public distro, will just not work.

I think we could support this by introducing simple flag enabled/disabled on the admin/hosting/settings page, and when enabled, it will use writable permissions on every site verify.

This could allow to enable the write access temporarily, to allow running plugin/app manager and then reverting write permissions by disabling the switch and runing site verify again.

It could be maybe more fancy, but I prefer simple solutions, if possible, so I don't think we need separate task just to turn on/off the write permissions per site.

NOTE: while it is not a job posting, Omega8.cc will be happy to sponsor this feature with some bounty in cash!

CommentFileSizeAuthor
#17 patch_commit_9877d2824ebc.patch4.37 KBomega8cc
#9 patch_commit_7aa756839366.patch5 KBomega8cc

Comments

hyperglide’s picture

hyperglide commented
Version: » 6.x-1.2

This thread has not had a comment in several months.

Reading over the words of omega8cc I hope to spark some interest in this project as I would be one of the users interested in this feature.

steven jones’s picture

steven jones commented
Status: Active » Postponed (maintainer needs more info)

Possibly this is a good idea, is it possible that sites can be made to only touch within their sites folder, and not the platform itself? If so, this might be a useful addition I suppose.

I wonder if this would be best handled as a sandbox project, and then we could pull it into Aegir. Although we don't want to Aegir to dictate policy, updating modules and themes from the front end is cool, but could break sites very easily, whil Aegir provides fairly simple processes for updating sites safely.

tomdavidson’s picture

tomdavidson commented

Steven Jones' direction may be better - it would just work with out extra steps, but I do not mind requiring Aegir permissions to be able to install modules/features/apps. This seems more of a developer task than a site or content admin task.

The permissions toggle could be another site task and could even automatically schedule verify to restore the tighter permissions after the app is installed. Seems like the ux side would be rather easy. The functionality of restoring the permissions already exists.

How does Aegir/provision preform its existing file permission functionality? I was going through he API looking hoping to find the verify function that does the permission modifications so I can look at it as a reference. Can someone point me to the right one?

br, tom

tomdavidson’s picture

tomdavidson commented

I was convinced that a new task module was needed that could expose a time limited permission override task to a client for a particular site. In trying to learn about creating a new Aegir task, I stumbled upon #1348732: Use filetransfer authorization for installs so write access to sites directory is not necessary. that appears to solve the App issue.

Do I understand correctly?
br, tom

omega8cc’s picture

omega8cc commented
Version: 6.x-1.2 » 6.x-2.x-dev
Status: Postponed (maintainer needs more info) » Active

@tomdavidson

We tried this patch and it solves the problem only partially - it makes Apps module using D7 native Plugin Manager to finalize the setup, so there is a step with using your FTP credentials etc, and maybe it works when your FTP account is not under chroot, as it is with secure Pure-FTPd server. Otherwise it doesn't work because it is trying to cd with full system path to sites/all/modules.

I really don't like the idea to rely on the buggy D7 native Plugin Manager - see some Aegir related discussion from the past: http://groups.drupal.org/node/24709 - but I'm also not sure if using our own permissions switch makes this stuff any better. It could make it simpler, as it really looks awful when you have to make an extra steps because of adding Plugin Manager to the process which is intended to give the end user a smooth "App Store Experience" and not some half-baked UX.

We still need to remember that using Plugin Manager and Apps is really against essential Aegir best practices, yet, whatever solution we will develop to support them for people who care less about best practices and more about "App Store Experience", we should KISS.

tomdavidson’s picture

tomdavidson commented
Title: Introduce simple switch for changing write permissions to support plugin manager (Drupal App Store) » The is

Thank you for the additional info. To make sure I understand correctly:

  • App is not compatible with Aegir best practices - full stop.
  • There is no clear path rectifying the incompatibilities, hence the suggested "work around".

I see two different use cases for the work around:

  1. An operator decides they want App functionality on a particular platform and enable such when creating the platform. For the sake of discussion we can think the platform is going to use an App client that only installs known and tested Apps from a known and tested source. Any instance of this platform is able to use the Apps as intended by App's design.
  2. An operator gives client accessible flag, such as a site task, that temporarily enables write permissions for Apps for that particular site instance. Once flagged the client would then log into the site's App manager to install the app. The site would then be re-verified and secure permissions restored.

For the present, an operator could create a platform of say OpenPublic that already has 6 or so apps downloaded, but not necessarily enabled. Site managers could use the app ux to enable or disable the selected apps and there would still be a clear/controlled path for Aegir best practices.

For the future with work around #1, and Aegir operator would enable the App functionality on a specific platform. I think these platforms could define an App repo or store. When a site is migrated to a newer version of the platform, Aegir would check to see if the App was available with the same UX that exists with modules.

As for #2, how would migration be handled? Would the Aegir flow be completely broken? If I understand right, this is the work around initially suggested. Would we offer an Aegir module that created a new site task? This task could be enabled only for specific platforms and could queue up verify after 30 min to restore the permissions.

If Apps was multi-site aware and only needed write permissions to /sites/site-name rather than /sites would it work (although there would still be the issue have what Aegir does after the App is installed)?

tomdavidson’s picture

tomdavidson commented
Title: The is » Introduce simple switch for changing write permissions to support plugin manager (Drupal App Store)
drupalninja99’s picture

drupalninja99 commented

I agree with your assessment:

#1 If the platform maintainer installs the apps as part of the platform then the user gets the friendly UI and the app is merely 'enabled' and not downloaded.
#2 It would be nice if there was an option to download the app in the 'client' folder and so that they would have to maintain it versus the platform maintainer having to verify compatibility with every app in the store. I think the idea behind the app store is that it delegates some responsibility to the 3rd party app maintainer, whereas for the platform maintainer in aegir, it essentially is just an extension of the platform that has to be continually tested/maintained just like any other aspect of the platform.

omega8cc’s picture

omega8cc commented
Status: Active » Needs review
StatusFileSize
new patch_commit_7aa756839366.patch5 KB

OK, the trick is ready to use, tested and works fine. Attached patch makes all required directories world writable temporarily on Password Reset task, but only if Apps module exists, and it allows you to install Apps easily, with absolutely smooth user experience, via browser only . When done, simply re-verify the site to restore default, safe permissions. It also includes not really related support for also temporarily writable local.settings.php file, as discussed elsewhere.

realityloop’s picture

realityloop commented

Appears to work for me

BManuel’s picture

BManuel commented

Hi,
From what directory to run this patch?

omega8cc’s picture

omega8cc commented

@BManuel

~/.drush/provision/

omega8cc’s picture

omega8cc commented
Status: Needs review » Needs work

Note that this may introduce critical security hole, as it is still possible that the user will forget to re-verify the site to restore safe permissions.

While I don't see any reason to create separate task in the front-end with some big red flag saying "this site and platform is open for remote attack!" when permissions are opened, since it is in fact Apps specific only, I think we could add a check for a control file the user would have to upload, say, as sites/all/modules/.apps-allow to make it to work. This would keep it completely secure for all others who are using Apps, but automatically enabled on install, like it is done in OpenChurch distro, so they never need to open write access there and may open the site and platform for abuse accidentally, just by running Password Reset task, which could be pretty silly.

Also, I will split the patch to make the local.settings.php stuff separate.

BManuel’s picture

BManuel commented

I could not agree with you more, check should be absolutely mandatory for something like this.
Thanks omega8cc for all your help. Any idea when this gets committed?

omega8cc’s picture

omega8cc commented

I will submit a patch for review later today, but I have no idea if this is something to be considered/committed in the Provision core, as it is rather quick and dirty hack/shortcut and not a properly implemented feature.

BManuel’s picture

BManuel commented

Understood, but at least we can try to add to barracuda next release, to perform the auto patch during upgrades of fresh install

omega8cc’s picture

omega8cc commented
Status: Needs work » Needs review
StatusFileSize
new patch_commit_9877d2824ebc.patch4.37 KB

New patch includes only Apps specific stuff. It checks first if the /sites/all/modules/apps-allow.info control file exists before checking for various Apps module locations and changing permissions. It always reverts permissions to secure default on verify, even if there is no control file and no Apps module, just in case they were removed before running the site verify task again.

BManuel’s picture

BManuel commented

Applied patch successfully, tried to install an app, it asked for ftp passwd. Now I realized I have never really used ftp, always did ssh with a special account that I created. So tried o1.ftp and it failed. updated the passwd, still no successful connection. Can we bypass this ftp process. As I have zero luck getting my ftp to work. btw I assume system is using pureftpd, if yes, then why after doing "passwd o1.ftp" ftp access still denied
Thanks
bob

omega8cc’s picture

omega8cc commented
Title: Introduce simple switch for changing write permissions to support plugin manager (Drupal App Store) » Introduce simple switch for changing write permissions to support apps (Drupal App Store) with plugin manager disabled

@BManuel

It should never ask for FTP access in BOA as we already disabled that horrible plugin manager by default, so you are using some older BOA version probably.

The reason why it doesn't work with FTP in BOA is that there is a virtual chroot, so it will fail to understand absolute system path to files used by plugin manager. It will never work and is not needed.

If you have issues, please open new issue in Barracuda or Octopus queue instead.

Note for others: you need this line in your global.inc to really benefit from this patch:

$conf['allow_authorize_operations'] = FALSE; // disable insecure plugin manager

I'm changing the original title to reflect this requirement.

BManuel’s picture

BManuel commented

I am using the verson 2.02 I believe that is the latest. I will open a new issue for this shortly

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Version: 6.x-2.x-dev » 7.x-3.x-dev
Issue summary: View changes

New features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.

helmo’s picture

helmo commented
Status: Needs review » Needs work

It feels wrong to do this in provision_drupal_drush_exit().

I would be more comfortable with this in a contrib module.... although that would probably require some extra hooks.

jon pugh’s picture

jon pugh
he/him
Primary language English
Location Newburgh, NY
commented

Just a side note, Features.module now has a "Generate Feature" button in the web UI that tries to recreate the feature in place.

This only works if the apache/nginx user can write to the features folder.

If this was implemented, we could allow site builders to click a button in the site they are building to export their changes to code.