Read and Fix Basic HDFS Permissions

Introduction

The retailer's analyst needs to read a product dataset, but should not be able to change it. The file is present and its blocks are healthy, yet another user can still receive Permission denied. Storage health and authorization answer different questions: is the data available, and is this identity allowed to access it?

HDFS uses an owner, a group, and permission bits to decide basic access. You will work as the ordinary owner, labex, and share a dataset with the prepared analyst identity through the bigdata group. A separate ordinary identity, nobody, will represent someone outside that group. The NameNode runs as hdfs; you are not the HDFS superuser.

You will read the existing permissions, establish group read-only access, and reproduce a directory-traversal problem. These checks use HDFS permissions, not local Linux file permissions. The environment is a simple-authentication teaching setup, not a demonstration of secure production authentication such as Kerberos. All fixtures are independent of previous labs. Use the Terminal.

Read the Access Rules

In this step, you will identify the owner, group, and access modes of a private dataset.

Start in the local project directory:

cd /home/labex/project

The HDFS -ls -d option lists the directory entry itself rather than its contents. Inspect the directory and file together:

hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt

The important fields should include these modes and identities; sizes and timestamps vary:

drwx------  ... labex labex ... /user/labex/basic-permissions/team
-rw-------  ... labex labex ... /user/labex/basic-permissions/team/products.txt

The first character describes the object (d for a directory, - for a file). The next nine characters form three groups of three: owner, group, and other users. r means read, w means write, and x means execute or, for directories, traverse. A dash means the corresponding permission is absent.

For a file, read allows reading its contents and write allows modifying it. For a directory, read allows listing names, write controls creating or removing entries together with traversal, and execute allows passing through the directory to access a named child. Reading a file therefore requires permission along the path as well as on the file itself.

The current directory mode gives labex full access and nobody else access. The file gives labex read/write access. Confirm that the owner can read it:

hdfs dfs -cat /user/labex/basic-permissions/team/products.txt

Expected text:

notebook pen
folder notebook

Save the initial listing using local output redirection:

hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/initial-permissions.txt

You have identified a private file, rather than a missing or damaged file. The next task is to grant the intended group only the access it needs.

Share with a Read-Only Group

In this step, you will grant the bigdata group directory traversal and file reading, then test the analyst's access.

The prepared labex and analyst users are both members of bigdata. HDFS -chgrp changes an object's group. As the owner and a member of the new group, you can set it without becoming the HDFS superuser:

hdfs dfs -chgrp bigdata /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt

Set the modes with -chmod. Each numeric digit summarizes one set of permissions: r=4, w=2, and x=1. Add the needed values for owner, group, and other:

Apply the directory mode:

hdfs dfs -chmod 750 /user/labex/basic-permissions/team

Apply the file mode:

hdfs dfs -chmod 640 /user/labex/basic-permissions/team/products.txt

Now test the actual analyst identity. sudo -u analyst runs only this command as the prepared ordinary user; the absolute HDFS client path selects the same tool. This is a test of another identity, not an instruction to run normal file work as an administrator:

sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt

The same two product lines should appear. The group can traverse the directory and read the file.

Test writing too. -appendToFile would append a local file's contents to an HDFS file if access allowed it. The provided read-only probe in /tmp contains an extra label that must not become part of the trusted dataset. It is outside the private local home directory so the ordinary test identity can read it; this isolates the HDFS write permission being tested. The next command is expected to fail.

sudo -u analyst /usr/local/bin/hdfs dfs -appendToFile /tmp/labex-hdfs-write-probe.txt /user/labex/basic-permissions/team/products.txt

Look for Permission denied and a write-access indication. That failure is the desired result: the analyst can read but cannot append. A nonzero command exit status is normal for this intentional denial; continue with the next step. Making the file writable by everyone would remove this protection.

Diagnose a Directory-Traversal Problem

In this step, you will change one permission bit, observe the resulting access failure, and restore only the needed access.

The file currently allows group reading. Predict what happens if the directory lets group members list names but no longer lets them traverse into the directory. 740 keeps owner access and group read while removing group x:

hdfs dfs -chmod 740 /user/labex/basic-permissions/team

Read the same file as the same analyst. The next command is expected to fail.

sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt

The access-denied message should point to missing traversal access on the directory. This is not fixed by adding more read permission to the file: the path must be traversable first. Restore the directory's group x bit by returning to the practiced mode:

hdfs dfs -chmod 750 /user/labex/basic-permissions/team

Confirm that analyst reading works again:

sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt

The original two lines should return. Finally, test an ordinary identity outside the sharing group. nobody is used only as this lab's unrelated identity. The next command is expected to fail.

sudo -u nobody /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt

The denial confirms that group sharing did not make the dataset public. Save the final listing:

hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/final-permissions.txt

Read the result:

cat /home/labex/project/output/final-permissions.txt

The directory should show drwxr-x--- and the file -rw-r-----, with owner labex and group bigdata. Compare those meanings with the initial private modes. You granted a specific group the minimum needed access, rather than turning off permission checks or using 777.

Summary

You read HDFS owner/group/other modes, assigned a sharing group, and used different modes for a directory and a file. Real identity checks confirmed that the analyst could read but not write, while an unrelated user could not read.

By removing and restoring directory traversal, you learned why a readable file can still be inaccessible through its path. In the next challenge, you will locate and repair a similar sharing problem independently.