In this lesson, we're going to be discussing
how to troubleshoot user permission issues.
One of the most important skills you'll need
is the ability to troubleshoot the inevitable issues
that'll arise in your systems.
You should always follow a general model
for troubleshooting any type of operating system problem
that you may come across,
such as using the seven-step troubleshooting method
you learned about back in your CompTIA A+ studies.
Often you're going to find
that the reason something isn't working
is because you're facing some sort of permission issue.
When this occurs,
you need to put your troubleshooting skills to work
and diagnose and solve those issues related to permissions.
Now, troubleshooting usually begins
with the identification of a problem
and it doesn't end until the services have been restored
and the problem no longer adversely affects our end users.
Troubleshooting can take many forms,
but all approaches have the same goal,
to solve a problem efficiently
with a minimal interruption to services.
Now, there are a lot of different strategies
for troubleshooting and they can vary in their approach,
but all of the troubleshooting models attempt to enable you
to move in a methodical and repeatable pattern.
The CompTIA troubleshooting model contains seven steps.
First, we have identifying the problem.
This includes things like gathering additional information,
duplicating the problem if you can,
questioning users to gain experiential information,
identifying the symptoms,
determining if anything has changed,
and approaching multiple problems as individual problems.
Second, we're going to establish a theory of probable cause.
This is where the troubleshooter questions the obvious.
They consider multiple approaches
and they look for the root cause of the problem.
Third, we want to test the theory to determine the cause.
Fourth, we want to establish a plan of action
to resolve the problem.
We do this while identifying
the potential effects of our plan.
Fifth, we're going to implement the solution,
meaning we're actually going to try what we think
will solve the problem.
Sixth, we'll verify full system functionality,
verifying everything is working
and we actually solve the problem.
Seventh, we'll document our findings,
our actions and the outcomes.
As a general guideline, whenever you're denied permissions
when you expect to have those permissions, or vice versa,
you get permissions when you're expecting to be denied,
you should always verify the permissions
of the relevant object by using the ls -al command.
This will often save you a lot of guesswork as many issues
simply coming down to having the wrong permission
being applied for a particular user
or system administrator or a piece of software or a group.
Just like with permissions,
you should always use ls -al to verify the user
and group ownership of a file or directory
whenever you're experiencing ownership-related issues too.
Despite having configure permissions
and ownership correctly, some issues can still arise
because users may not have been placed in the correct group.
Use the groups command by typing groups username
to be able to discover what groups a user is a member of.
Another issue that can occur is when a user creates files
and the default owning group is not what is expected.
Make sure the expected group is the user's primary group
rather than a secondary group.
In either case, use the usermod command
to change the group membership when applicable.
It may also be beneficial
to list all the members of a group
so you can identify which accounts
to add or remove as needed.
Now to help with this process,
there are two commands that are pre-installed
on some distributions.
This is known as lid and libuser-lid.
These two commands can be used to retrieve
all members of a group,
including members whose primary group
is the group being searched for.
Another useful command is getent.
The getent command,
which is available on some distributions,
will enable you to retrieve group members
of nonstandard authentication methods.
So remember, when troubleshooting permission issues,
it's important to follow a few guidelines.
First, follow an overall troubleshooting strategy
for any kind of troubleshooting task.
Always use a model that can produce repeatable results.
Second, always start by verifying an object's permissions
and ownership using the ls -al command.
You're going to use this to ensure users have the permissions
to work with a file if they're being denied access.
Always ensure users do not have permissions
that enable them to access files
beyond what they should have because we want to make sure
we're implementing lease privilege.
Third, make sure you verify any special permissions
that are needed are actually set properly.
Ensure objects don't have a mutable flag set
if you expect to modify those files.
Make sure you set the set user ID permission
on an executable if you need to run it with root permissions
for it to function properly.
Make sure you set the sticky bit
if you only want the owner and the root user
to be able to delete that object.
These are the kind of things we're talking about
with verifying special permissions.
Fourth, ensure objects have the proper owner
and owning group set.
Set the set group ID permission on a directory
whenever you want new files
to take on that directory's group ownership.
Use the groups command by typing groups username
to verify the groups a user is a member of.
Modify group membership if necessary to ensure access
or lack thereof for specific users.
If you're in doubt, you can always use tools like lid
and getent to view members of a specific group.
By keeping these troubleshooting guidelines in mind,
you can quickly identify permission and ownership issues
and get your users back up and running quickly.