Your problem isn't likely to be so much of a login design issue; it is probably a specific implementation issue with that form. Is the same form capable of either entering or editing data? If so, then your problem is in the way you set up to enter the data.
The form's method of blocking action should be that it displays data for every record but, for extant records not created by the current user, it should LOCK the controls (control.Locked=True). You can do this in the form's OnCurrent event, which gives you the chance to look at the current record before the user sees it so you can test whether editing would be allowed.
In theory, if you try to create a new record, when the form navigates to that new record it exists already but is empty. So if you test for who is allowed to edit the record and the record is marked with no owner, claim the new record and let editing happen.
Not saying you SHOULD do this, but if you used command buttons to trigger SAVE, UNDO, CREATE, and DELETE actions then the trick would be that you don't disable the CREATE button regardless of record ownership. (But you DO disable the SAVE button.) Search this forum for discussions of preventing navigation on a form. There are command-button wizards to perform every one of those functions I just named. Might be worth a peek, even if you later decide it is too much of a pain in the toches.
The idea of checking username, password, and access level from a table is almost perfect. Almost. IF you have a domain-based environment or other strict login security where you have your user id and password in order to even use the machine you are on, there IS one improvement to be made. If you don't have this situation, you don't need to do anything different.
IF AND ONLY IF you are in a domain environment or a strict login environment, you can bypass a login screen completely and instead get the username from Environ("Username") to see who is logging in. For "strict login security" cases, that person had to have already logged in with a username and password or some other multi-factor authentication method of getting in. You can take advantage of that strict environment and "trust" the login. Then your username becomes that person's login name. You can have actual names in your table of roles and user IDs and such in case you need to use that info, but otherwise you can have a very smooth and trustworthy login.
If this DOES NOT APPLY to your situation, change nothing in your general design. Just understand that for Access, it would be good to establish some sort of scrambling algorithm for the passwords because a good or persistent hacker would be able to see passwords pretty easily if they wanted.