You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had a thought that it might be useful to have a sudo command such as:
@sudo SomeName SomePassword=Some command
This would basically let one user @force another user assuming they have that user's password, and would enable people to remote control their wizard characters (or their alts) for one off tasks easily. It would use most of the same code as @force under the hood, it would just alter the permission intake.
Some questions come to mind as far as security; we could have an @tune that only lets certain people use sudo (kind of like sudoers on Linux). And failed attempts to @sudo should be logged, though follow the same rules as other logging settings:
Successful attempts would go to the command log (with maybe a notation that someone used sudo in the status log?) and follow the same rules re. command log settings
Failed attempts will go in the status log. If log failed commands is enabled, we'll show the whole command. Otherwise, we'll just say like X tried to sudo to Y and failed.
On my MUCK, we log as little user input as possible so I wouldn't want to log the user input on a successful attempt.
This is just a random thought, total back burner, no immediate need.
The text was updated successfully, but these errors were encountered:
I had a thought that it might be useful to have a sudo command such as:
This would basically let one user
@force
another user assuming they have that user's password, and would enable people to remote control their wizard characters (or their alts) for one off tasks easily. It would use most of the same code as@force
under the hood, it would just alter the permission intake.Some questions come to mind as far as security; we could have an
@tune
that only lets certain people use sudo (kind of like sudoers on Linux). And failed attempts to@sudo
should be logged, though follow the same rules as other logging settings:On my MUCK, we log as little user input as possible so I wouldn't want to log the user input on a successful attempt.
This is just a random thought, total back burner, no immediate need.
The text was updated successfully, but these errors were encountered: