I want to change the server's owner for my private bot.
I tried guild.setOwner() but it did not work...
You can't.
To change the owner of a server, you must be the owner. And as far as I know, bots can't have ownership of servers.
When I say that you must be the owner, I mean the account that is running the function. If you are the owner, and you're trying to change the owner with the bot, you won't be able, because the bot is not the owner.
EDIT: Aparently bots can have ownership of a Discord Server, but the bot must create the server.
To change the ownership of the server (if the bot has it) you do <guild>.setOwner(<GuildMemberResolvable>)
https://discord.js.org/#/docs/main/stable/typedef/GuildMemberResolvable
Related
I dont know if im doing something completely wrong or im just missing the point of SQL Server security.
Here's what I'm trying to do using SSMS, a simple two-level access (network\DomainUsers, network\SQLAdmins).
Domain users would not be unable to view any tables within SSMS but can access data via applications.
SQLAdmins see all
To start with I thought I had it cracked by setting up a new server role for domain users and assigning view and database/definition permisions then removing these from the public role - no joy!
Staying with the same settings I then branches down to the table to grant permissions but again no joy.
I've setup several roles / users and applied all forms of permissions but as soon as database/definition is altered in public it overrides everything. I thought public was a default setting which then became redundant when other roles became active?
Can someone please point me in the correct direction before either my head pops or the machine learns to fly :-)
SSMS: v17.8.1
SQL Server: 2012
Depending on how you actually defined your roles (which isn't clear from your question) it can simply be that you DENY view any database on the public role. This will in turn make it so everyone is denied. Because everyone is always a part of the public role. (This is why messing with the public role is a bad idea).
Deny's trump Grants. So no matter what you grant them later on, the deny overrides it. So if you denied it at the top level, it will stay like that no matter what you specify later on.
The exception to this is, that you can always see the objects that you own. And members of the sysadmin server role can't be denied since they always jump in as the owner. So you can technically hide all databases by revoking view permissions on the public database. But then you need to make a shared login and assign ownership to the databases that you want to be viewable.
Of note is that in this case, it means they can do whatever they want in said databases. Since you can't 'deny' them rights in something they own (which is why they can view it in the first place).
In overall, you're better off finetuning roles on the DB level, or making some custom server roles depending on what you want to accomplish.
Note, unless you messed with the public role. Logins with no user mapping in a database can't see the tables within a database, they can only see the existance of the database itself.
We ran into an issue yesterday with a stored procedure that calls sp_send_dbmail. The stored procedure is called from a scheduled job, and the job is explicitly set with a domain account that has full control on a folder, on the same server.
The issue was with attachment, where when trying to send an email with an attachment I was getting an error message: "sp_send_dbmail file attachment invalid"
So when I added the Engine service account, which is different from the SQL Agent, it worked fine. Looking at the error and how it was fixed, the answer is clear, sp_send_dbmail is using the Engine account and not the Agent account.
The thing is, that the other DBA claims the Engine account was never granted access to the folder, only the Agent account. So I was wondering if this could be due to some change in the permissions for the Agent account.
That's very weird.
I was hoping if you guys could point me at some documentation, as I couldn't find anything about it.
This answer says:
There is a conversation_id, which is the same at both endpoints.
And there is conversation_handle, which must be different at each
endpoint.
So I thought it would be useful for troubleshooting to write the conversation_id to an audit table at each endpoint of a conversation. That way I could easily track down the audit information at each endpoint for a given conversation.
The problem is where to pick up the conversation_id from. I had originally thought I could look it up from sys.conversation_endpoints against the conversation_handle of the message just sent or received. However, the database users that send and receive messages do not have permissions to see the metadata in sys.conversation_endpoints.
I could get around that by making the users sending and receiving messages database owners but I would prefer not to for security reasons. What are the minimum permissions they would need to see the records in sys.conversation_endpoints? Alternatively, how else could I read the conversation_id of a message that had just been sent or received (from the code doing the sending or receiving, which would not have dbo or sysadmin permissions)?
Edit: I read the Books Online article about Metadata Visibility Configuration which states
the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission
For catalog views such as sys.tables or sys.procedures it's fairly obvious what the securables are that the user needs to be granted permission to. But what are the securables listed in sys.conversation_endpoints: conversations, conversation endpoints? And how do you grant permissions to them? The user already has permission to begin a dialog or end a conversation so I would have thought it would already have adequate permission on a conversation.
The best place to get it is from sys.conversation_endpoints.
Whenever you are faced with the issue that your application requires privileges not held by the current user the best option is to leverage code signing. SQL Server allows an administrator to inspect and sign stored procedures, using certificates, and grant permissions to the signature. This allows an user to invoke the procedure and the procedure can access information not directly accessible to the user.
See signing Activated Procedures for an example.
As to why you can't see your own conversations: imho it's a bug. Running sp_helptext 'sys.conversation_endpoints' shows the permissions filter applied:
CREATE VIEW sys.conversation_endpoints AS
SELECT ce.conversation_handle,
...
FROM sys.conversation_endpoints$ ce
LEFT JOIN sys.syssingleobjrefs f
ON f.depid = ce.service_id
AND f.class = 21
AND f.depsubid = 0 -- SRC_SVCTOQUEUE
WHERE has_access('CO', f.indepid) = 1
The view shows conversations for which the user has CONTROL access over the queue of the service to which the dialog belongs (it takes some know-how about syssingleobjrefs to understand what the view condition is, but that what it translates to). The permission check should be for RECEIVE permission, because that is the permission required to BEGIN DIALOG/SEND/END messages on this service:
To begin a dialog, the current user must have RECEIVE permission on the queue for the service specified in the FROM clause of the command and REFERENCES permission for the contract specified
To send a message, the current user must have RECEIVE permission on the queue of every service that sends the message.
The MSND is actually wrong on the topic of END CONVERSATION permissions when it says 'To end an active conversation, the current user must be the owner of the conversation, a member of the sysadmin fixed server role or a member of the db_owner fixed database role'. The required permission is the same as one for SEND (this can be easily tested).
It can be easily argued that if you can manipulate a securable (and SEND, END are clearly manipulating conversations) then one should be able to see the metadata of the securable being manipulated.
I spent a long time yesterday to configure for my CouchDB instance in order to create a little app and letting CouchDB manage authentication and authorizations for me.
So I ended up with something like that :
On top of everything I've got a server admin, who basically is god on my CouchBD instance.
Then I created a database named "mydatabase" (for example) and added the role "mydatabase_dba" as admin and also the role "mydatabase_user" as reader.
I also created a database named "_users" which contains all the database admins and users with their roles and also a design document named "_auth" which manages authorizations.
Only the server admin is admin of this database, and I added users with role "mydatabase_dba" as readers. Then, for those of you who knows about it, I modified the "validate_doc_update" field o the "_auth" document so that users with role "mydatabase_dba" can only deals with users with role "mydatabase_user".
So, to summarize at this point :
server admin is still god
users with role "mydatabase_user" can connect to "mydatabase" but they are just readers
users with role "mydatabase_dba" are admins of "mydatabase"
users with role "mydatabase_dba" can connect to database "_users" where they are readers
users with role "mydatabase_dba" can only manage users of role "mydatabase_user" in "_users"
Hope this is clear :D
What I can do now is create an application that will not manage users itself, but let users connect to CouchDB directly (transparently).
The problem come when it deals with users creation/update/deletion.
Because only users with role "mydatabase_dba" can access to the "_users" database and work on users with roles "mydatabase_user", I need at some point to connect to CouchDB as this db admin.
I have two solutions :
Create a user interface into my app that will let the admin connect and do what he has to do
or
Make some more code and let the app do it automatically, this is the solution I prefer, but the problem is : I have to store the admin credentials...
Sorry for the long introduction but I had to describe the landscape first :)
I created a post yesterday about how I could secure the connection between my app and the CouchDB instance : here
The solution I was given is to use HTTP over SSL (/TLS) to secure the communication. I'm okay with that, but now I have another concern, maybe I'm paranoid, but because my app will need to connect as "mydatabase_dba", I have to store its credential somewhere.
But how to store them securely ? As said in my previous post, even if I store the hashed password instead of the plain text password, if an attacker access my app source code, he'll have my admin credentials...
An application should never have an administrative rights. It should only be given the bare minim rights it needs to function. If the application needs some administrative rights, make sure it has as few as possible. Other than that, most of the time these credentials are stored in plain text in some file that only your application can access.
Never commit this text file into your source code manager (Subversion, Git, etc.)! Placing the file into a running system must be a step in the installation procedure.
I have a SQL Server 2005 database that I'm trying to access as a limited user account, using Windows authentication. I've got BUILTIN\Users added as a database user (before I did so, I couldn't even open the database). I'm working under the assumption that everybody is supposed to have permissions for the "public" role applied to them, so I didn't do anything with role assignment. Under tblFoo, I can use the SSMS Properties dialog (Permissions page) to add "public", then set explicit permissions. Among these is "Grant" for SELECT. But running
SELECT * from tblFoo;
as a limited (BUILTIN\Users) account gives me an error "Select permission denied on object 'tblFoo', database 'bar', schema 'dbo'". In the properties dialog, there's an "Effective Permissions button, but it's greyed out.
Further, I tried creating a non-priv account called "UserTest", adding that at the server level, then mapping it down to the "bar" database. This let me add UserTest to the "Users or Roles" list, which let me run "Effective Permissions" for the account. No permissions are listed at all -- this doesn't seem right. The account must be in public, and public grants (among other things) Select on tblFoo, so why doesn't the UserTest account show an effective permission? I feel like I'm going a bit crazy here.
ASIDE: I am aware that many people don't like using the "public" role to set permissions. This is just my tinkering time; in final design I'm sure we'll have several flexible (custom) database roles. I'm just trying to figure out the behavior I'm seeing, so please no "don't do that!" answers.
UPDATE: Apparently I know just enough SQL Server to be a danger to myself and others. In setting permissions (as I said, "among others"), I had DENY CONTROL. When I set this permission, I think I tried to look up what it did, had a vague idea, and decided on DENY. I cannot currently recall why this seemed the thing to do, but it would appear that that was the reason I was getting permission failures. So I'm updating my question: can anyone explain the "CONTROL" permission, as it pertains to tables?
You only need to have SELECT rights. In raw SQL (see the "script" icon/button in your dialogue box), it's GRANT SELECT ON dbo.tblFoo to public. This is the only permission needed to view the data,
In this case, the error message explicitly mentions "deny". "DENY" is a right in itself, so it mentions it,
If you had no rights, you'd get the message (very approximately) "tblFoo does not exist or you do not have rights"
"DENY CONTROL" is mentioned here. In this case, you denied all rights to the public role.
The grantee effectively has all
defined permissions on the securable
Assuming "UserTest" is a domain user account, connect as a member of the sysadmin role and run
EXEC MASTER.dbo.xp_logininfo 'Domain\UserTest', 'all'
(substituting your domain name for "Domain")
this will display the Windows groups etc. that the account is inheriting security permissions from and the level of access, e.g. you would expect to see something like:
account name type privilege mapped login name permission path
domain\usertest user user domain\usertest BUILTIN\Users
This will help troubleshoot where the account is inheriting permissions from, e.g. which Windows groups it is part of that have permissions to the database. If this all looks OK then I would follow your own advice and not mess with the public role.
Create a database role in your
database
Assign explicit permissions for that
role
Create a server login for your user
account
Open the server login, go to the
User Mapping section, click on the
database and select the database
role you created