p.s. - Eloy - Do you think that we should label this as a possible security issue? I could see the argument being made but I don't see too much harm in it.

I, for example, have a Moodle set up where I am giving course space to teachers at other institutions. They want to use my "MoodleReader module" but for various reasons (mainly the resistance of local staff admins) can't set it up on their own institution's server. I would like them to be able to back up the users in their courses and then restore them to their course on my Moodle so that I don't have to intervene each time. Without the current "bug" they would have to have the students enroll via the mail/confirmation process. This simply would not work efficiently with a large number of students – too many misentered email addresses or other ways that the confirmation message might go astray.

We let the teachers import courses from any moodle installation they want and sometimes it is not possible to do the backup of original course without user information. If we can set a permission to not allow they create users during backup would be great.

really I don't think that using "moodle/user:create" neither "moodle/backup:createusers" is the proper solution. For me there are more "variables" is this problem. Let me explain the thing with one simple use-case:

Imagine server "A", with course "C" and student "S" enrolled (and with forum posts and other activity on it).

Teacher makes backup of course "C". Obviously it will include information of user "S" plus all his forum posts.

Then, for any reason, student is "deleted" from server A (so his login is changed along with other personal information), although forum posts and related info continues there, associated with the "deleted" user.

Then, teacher tries to restore backup into a new course, or into the same course (A) but deleting data first.

At this point, student "S" won't be found anymore in the server (check is performed by login - another problem - that has been trashed by the deletion), so restore MUST re-create it or, later in the process, when restoring forum posts, there won't be any user to link the info to). If we rely on any capability to decide if users will be created or no, we can easily end with non-restorable information. So, simple check isn't enough at all (nor for restoring in a different server nor for restoring in the same server, it's important to note that the problem can happen in any server, as the use case above demoes).

So, IMO, we can follow only 2 "safe" approaches:

• - The radical one: Preventing to restore ANY user related-info if user lacks the "moodle/user:create" (or "moodle/backup:createusers") capability. Note I'm not talking only about to prevent user creation BUT about to prevent restore of ANY user-related info (forum posts...) what can lead to a BIG loss of functionality for, say, 95% of sites. Of course, it's 100% safe, because now new users will be created nor information will be "orphaned". This is the approach we recently followed when restoring backup files containing mnet users (MDL-17009) that now are only allowed to "moodle/user:create" users. Of course, we followed that approach for mnet users because it only affects "0.0001%" of sites (those using MNET). The question is if the same approach is extensible to all course backups.

• - The correct one: It involves to pre-check in the early steps of restore (before performing the restore of activity itself), if all the users to be added already exist in destination server. If that pre-check passes, then restore can continue because we have assured that all the activity will be properly linked to existing users, hence nothing will became orphaned. Obviously this pre-check will be performed when the user misses the "moodle/user:create" (or "moodle/backup:createusers") capability only. Users able to create users don't need the check at all. But we have two big problems with this pre-check: First of all, it doesn't fit well in current backup/restore architecture (it will be really hackery to introduce such a check). And second, we need to improve our algorithm of detecting existing users (see MDL-15598 for example), because current match by "login" is really inaccurate).

So... summarising, we have two alternatives:

• Completely prevent restoring backup files with user info to users missing the "moodle/user:create" (or "moodle/backup:createusers") capability. Easily doable, although perhaps the default for teachers, for better BC should be "moodle/backup:createusers" => allowed.
• Implement a complete user pre-check with an stronger match than the current one. More complex to implement but also tons better solution.

Sorry but the long comment, just trying to explain that it isn't only a matter of adding one capability (unless we want to be radical). Please comment, ciao

This is fine, but the site administrator needs to be able to elect whether this pre-check is enforced or not. As I stated in my comment of 22/Apr/09, I have sites where I need to permit others to do such restores. Can there be a capability created which, if assigned, would permit specific users to restore without the strict check?

yes, I think we can use that new proposed capability "moodle/backup:createusers" to allow users not having "moodle/user:create" (admins) to bypass any check/restriction. No problem with that.

They keys here are which approach we must follow (the "radical" or the "correct" one above) and which defaults (for each legacy role) should we apply to that new capability "moodle/backup:createusers".

Ciao

IMHO, only admins should get "moodle/backup:createusers" by default.

But the "radical" has its own merit.
As a case use, we at ULPGC, as in many Universities, synchronize users from external DB. We want adminds and teh liek to be able to create users on restore but nobody else. We instruct teachers to backup/restore courses from one year to other "Without user activity" and "without users", but there are always errors.

A configurable switch to disallow teachers to restore users &userdata would be very useful (now, we hack restorelib for this purpose): i.e. vote also for capability check to fall into no users/no user info restore when "moodle/user:create" is not allowed.

I'm aimed to do this in the "correct" way: new capability + pre-check all users, but it isn't trivial to implement now. I hope to be able to do so as we'll need that also for 2.0 (where I'm working now).

i have seen a commit at MOODLE_19_STABLE (http://git.catalyst.net.nz/gw?p=moodle-r2.git;a=commit;h=f484cb3e30e485958bafe54a391064e5d298d6c2) that adds the moodle/backup:userinfo capability, disabled by default for teachers.
Is it related to this issue? It checks for the capability in the backup process, but not in the restore. Maybe it should be two distinct caps...

both MDL-20834 (moodle/backup:userinfo) and MDL-20849 (moodle/restore:userinfo) are there to prevent completely any backup/restore operation related with user data. Not only the creation of users but anything related with users (like forum posts, assignment submissions...).

Both are being implemented right now and both will debut in Moodle 1.8.11 and Modle 1.9.7.

About how they are related with this issue, I'd say that only "tangentially"; they are more restrictive than the proposed "moodle/restore:createuser" as far as they prevent ANY operation with user info, not only account creation but ANY user info.

But, no matter of them, and how every site/institution decides to use them (note that, by default, they aren't granted to teachers!), the "moodle/restore:createuser" must land sooner than later, with proper pre-check and so on, as commented above. And will work together with the moodle/restore:userinfo one, so both will need to be allowed to successfully restore courses needing to create users.

I hope I'll be able to finish the bugs above (and some more I've pending for 1.8.11, 1.9.7 releases) and then, invest some time with this (new capability + proper pre-check).

Ciao