It depends on how well or how badly your security model is set up. In a good security model, where all users have permissions (roles, or groups in the old paradigm) explicitly granted; and users are explicitly added to the db (to grant access to the db), there is no problem. In fact many security conscious orgs delete guest (user) and public (group).
In a medium security set up, where the above is not done, where users are not explicitly granted access to each db, then they are using guest (or the public group). They have whatever permissions are granted to guest: usually select and reference to non-confidential tables only. You can grant insert/update/delete to guest, but that is asking for trouble. Check what permissions have been granted to guest/public, that will tell you if it is being used.
In a poor security model, what little security is set up, users may well be counting on guest, to access the db.
If you are using newer login/roles only, and not the older user/groups, then guest and public are a relic of the older paradigm, and can be deleted without further examination.
If you are cleaning up pas mistakes by predecessors. One way of andling your question is, just delete guest/public, and see who screams that they cannot access the db; then give them formal and chosen access as per your security model.
Auditing Security (In Sybase, MS, Oracle & DB2)
It is not hard to do, you just have to know what security is; what a good security model is, so that you have a measure against which you can compare the security you are auditing. The RDBMS systems allow for various levels and forms of security; implementing security is the job of the DBA (anyone with sso_role). Just like and SQL code (a) it doesn't exist until you put it in and (b) it is only as good (quality) as the knowledge and experience level of the implementor. Nothing to do with the vendor.
Personally, I find Sybase the easiest of all to Audit. I just walk in, run a couple of scripts and that tells me everything. "Digging in" is also easy: everything is located in catalogue tables (sys%, accessible via SQL.
Whether the configuration is secure or not depends in part on the implementation of a good model; and what you are comparing against. Get someone professional to do it. I do an aduit of security as a small part of a full Technical Audit which is only a few days; what I am saying is, if you have the scripts, and you know the job (security model; what is and isn't acceptable at each level), a security audit is half a days work. Depending on your knowledge and experience level, it will take a substantially more than that.
Reading some papers found that guest account can inherit the access level configured to public, is it true?
There is an awful lot of rubbish and half-facts on the web. The manuals are more precise (not suggesting they are perfect or that you can learn what is a good model or a good database from them, they are merely poduct manuals). That is true but stated completely incorrectly.
Old paradigm: Groups and users
• public is a Group within the db (not the server)
• guest is an User
• normally you add Users to the database (that allows them to connect but not access tables)
• when you add Users, you add them AS members of a Group.
• it would be onerous, if you had to then Grant [select/reference/insert/update/delete] for each table for each User
• therefore you Grant select/reference/insert/update/delete] for each table to selected Groups, once
• adding the User to the Group gives them all the permissions of that Group (I would not call it inheritance)
• an User can belong to only one Group
• with many tables and many different sets of permissions, this soon becomes a limitation
• granting permissions to both Groups and Users is a very silly thing to do, very messy, and hard to find/fix
Therefore yes, guest user always has the permissions of the public group, because that is the group it belongs to (unless you change its group).
Again, in a tight security model, both guest and public are disabled.
In a very tight security model, where access to the system, the server, is heavily restricted by other means; and where therefore, anyone accessing the server is allowed to (eg) select/reference all tables, then guest and public can be retained, and public granted select/reference to whatever tables are not confidential to an user.
New Paradigm: Roles
• Roles replace Groups
• Roles are server level, not db level, they operate across any db in the server
• Users can have more than one Role assigned to them
• that eliminates the limitations of the old paradigm, and eases the permissions administration
• you still have to add Users to each db, to allow them to connect to it
• but once, connected, they have (not inherit) whatever permissions have been granted to the multiple Roles they have
• if you change the permissions of the Group/Role, they are changed immediately across the database/server (not inheritance)