Simply put, you need to add an option "All account's rights", including all rights, added by extensions.

About sharing main account to bot: bots were created to hide mass automatic edits from users' watchlists. Bot policy, at least in ruwiki, forbid bot edits from accounts without bot flag, so "sharing scenario" contradicts the policies.

From a technical standpoint, there's nothing to prevent this feature from being added.

@dpatrick, @Bawolff, any objections from a Security perspective? The TL;DR is "Add an option to BotPasswords to just let the bot use every right available to the account instead of messing with grants."

@dpatrick

In T150526#2790196, @Anomie wrote:

From a technical standpoint, there's nothing to prevent this feature from being added.

@dpatrick, @Bawolff, any objections from a Security perspective? The TL;DR is "Add an option to BotPasswords to just let the bot use every right available to the account instead of messing with grants."

@Anomie No objections here. We discussed this in the weekly Security team meeting. We're for it.

IMO this would encourage unhealthy habits, T142308: Most extensions which add a user right should also add or extend a grant should be fixed instead.

@Tgr, could you please elaborate on what you mean by "unhealthy habits"?

In T150526#2816968, @Leloiandudu wrote:

@Tgr, could you please elaborate on what you mean by "unhealthy habits"?

Giving all bots all rights because it is insecure but convenient. (Then some attacker obtains a bot password for an admin account from some weakly protected VPN and gains high-privilege access.) I would much prefer the current system where giving more rights to the bot is more effort than giving less rights.

@Tgr, I would argue it's a self-deceit. The current grant list page is too complicated. If it was a simple "allow read-only access only" setting - then maybe your argument would be valid.
Instead the current grant list page is hard to use (a user is supposed to hover every checkbox to figure out what it does and decide if they need it) and confusing (it lists even the rights that are not actually available to the user). I'm pretty sure almost no one will use it as intended. Instead, most of the users are going to check every checkbox on that page and forget about it. And nothing can be done about it. So adding the 'grant all existing rights' checkbox is not going to change anything security-wise.

"Parent accounts" are not a concept that even exists right now - is this being worked on?

No, there are no "parent accounts". The reporter seems to have been thinking of a BotPassword as a "sub account" rather than as a rights-limited login to the existing account.

Perhaps, rather than grants, allow assigning each user right separately?
This would

1. Avoid issues of no grants including rights, limiting botpasswords (making T142308: Most extensions which add a user right should also add or extend a grant less important, and allowing users to access rights not added to grants without needing to wait for grant creation)
2. Allow finer control over rights granted using botpasswords - eg currently on enwiki the only way to grant extendedconfirmed also grants changetags, editprotected, and tboverride, which reduces the security of bot passwords by requiring that extra rights be granted
3. Eliminate the need for single-right grants[1]
4. Avoid requiring that certain rights be granted by forcing usage of the basic grant[2]
5. Simplify the interface of Special:BotPasswords - currently, each grant has an info message with it, but sometimes that message lacks the rights associated with the grant, requiring the user to go to Special:ListGrants to understand the permissions
6. Avoid showing information about rights to users without those rights[3]

[1] For examples, the rollback, viewmywatchlist, editmywatchlist, sendemail, privateinfo, globalblock, and oath grants only have 1 right associated with them, and the editmyoptions, uploadfile, blockusers, oversight, createaccount, checkuser, and setglobalaccountstatus only grant 2 rights
[2] To be able to use bot passwords, the authentication must also provide access to (if the user has the rights): autoreviewrestore, autocreateaccount, ipblock-exempt, torunblocked, globalblock-exempt, editsemiprotected, autopatrol, autoreview, autoconfirmed, nominornewtalk, skipcaptcha, purge, read, writeapi, abusefilter-view, abusefilter-log-detail, patrolmarks, unreviewedpages and abusefilter-log - even if the bot task is to purge pages, which just requires purge
[3] No local user groups on enwiki have autoreviewrestore, patrolmarks, unreviewedpages, item-term, property-term, item-redirect, item-merge, editextendedsemiprotected, editeditorprotected, autoreviewprotected, property-create, upload_by_url, validate, or oathauth-api-all, but they are still shown on the grants page, despite only causing confusion. Other grants include rights that the users may not have (eg 'delete`), where showing the right isn't helpful

@DannyS712 can you expand a bit more on the mechanics you are proposing? BotPasswords doesn't "grant" any permissions itself, it is used as a filter to limit which permissions of an account a specific session can use (with "deny all" being the implicit 'last rule'). The problem reported above is that some permissions are not available to "permit X". Exposing every possible permission to botpasswords would fix this, and allow for an account owner to only permit exactly what they need - but how would that "simplify the interface" ?

In T150526#5549669, @Xaosflux wrote:

@DannyS712 can you expand a bit more on the mechanics you are proposing? BotPasswords doesn't "grant" any permissions itself, it is used as a filter to limit which permissions of an account a specific session can use (with "deny all" being the implicit 'last rule'). The problem reported above is that some permissions are not available to "permit X". Exposing every possible permission to botpasswords would fix this, and allow for an account owner to only permit exactly what they need - but how would that "simplify the interface" ?

When logged in as DannyS712 bot, I see options to enable lots of grants that would do nothing:

1. The patrol grant includes patrol, review, and validate - bot accounts lack the first two, and no one has the third
2. The rollback grant includes rollback - bot lacks the rollback right
3. The blockusers grant includes blockemail and block - bot account lacks both
4. The viewdeleted grant includes browsearchive, deletedhistory, and deletedtext - bot account lacks all three
5. The oversight grant includes abusefilter-hide-log and suppressrevision - bot lacks both
6. The checkuser grant includes checkuser and checkuser-log - bot lacks both
7. The globalblock grant includes globalblock - bot lacks the globalblock right
8. The setglobalaccountstatus grant includes centralauth-lock and centralauth-oversight - bot lacks both
9. The oath grant includes oathauth-api-all - bot lacks the oathauth-api-all right

For the other grants, that include one or more rights the bot account does have, I then turn to Special:ListGrants to see what rights are included, where extraneous rights (listed above) are listed.

The current workflow is (at least for me) when enabling bot passwords:

1. View the list of grants
2. View the permissions associated with each grant
3. Allow the grants that include the needed permissions

Step 1 is cluttered by needless grant options, and step 2 is cluttered with needless permission options. By removing the need to check against the Special:ListGrants page, only showing the user rights that they can use, and removing the grants groupings, we would reduce the clutter and make it clearer how to grant each right, while avoiding the confusion of being shown grants that do nothing for the user but add another layer of complexity between the rights to be assigned and the interface to assign them.

I don't see any problem with letting botpasswords not filter out an access you don't currently have on an account - since that can change and you wouldn't have to change the botpasswords setting again.

Just to make sure I'm following you @DannyS712, is your suggestion to change the botpasswords from the selecting the grants (from Special:ListGrants) to all of the "rights" from that page (and possibly ensure that every existing "right" is available even if it isn't on the page)? If so , the page could just grey-down or sort down on the gui view selections that aren't currently applicable perhaps, but you could still select it if you really wanted to.

In T150526#5550033, @Xaosflux wrote:

I don't see any problem with letting botpasswords not filter out an access you don't currently have on an account - since that can change and you wouldn't have to change the botpasswords setting again.

Just to make sure I'm following you @DannyS712, is your suggestion to change the botpasswords from the selecting the grants (from Special:ListGrants) to all of the "rights" from that page (and possibly ensure that every existing "right" is available even if it isn't on the page)? If so , the page could just grey-down or sort down on the gui view selections that aren't currently applicable perhaps, but you could still select it if you really wanted to.

Either that, or just not showing the rights. But, it should be limited to rights that exist on that wiki - no one on enwiki needs to be able to assign property-create

An alternative solution to fix the original issue would be a last grant "Misc. rights" containing all rights which are not attributed to a grant, so that we keep the spirit "only add necessary rights for a given task" as Tgr said above (T150526#2818602) and if some extension has not attributed its rights to a grant (as in subtasks of T142308) there is a transitional solution for users.

Possibly such a grant would appear only if there are unattributed-to-a-grant rights, and possibly there would be a tooltip to warn the users this grant is a transitional grant and their targeted right(s) will be moved to a perennial grant in the future.

I’m not sure why this task has the priority High, it seems there is no work done at least since 3-4 years, is there?