Friday Hackathon: Can you build the "HR Drop Box"?...

TudorRaduta

Community Highlights

Thanks to the members who stepped in and moved the conversation forward on the Wednesday challenge:

@sa_sachin @Blue_bird @Trevor @Ad_astra @Architect_005

Strong solutions. Clear thinking. Respect.

Architect the "Perfect" Directory

Happy Friday! Today, we're doing something different. Instead of fixing a broken server, you are going to architect a solution from scratch.

This "mini-hackathon" challenges you to combine multiple RHCSA security objectives: standard permissions, special permissions, and Access Control Lists (ACLs).

Most people know how to use these tools individually. The real skill is knowing how to layer them together.

The Scenario: The "HR Drop Box"

The HR department needs a secure folder located at /srv/hr-dropbox.

You have the following users and groups:

Group: hr_managers
User: intern1
User: auditor

The Requirements:

Members of hr_managers must create, read, and delete files.
All new files must automatically inherit the hr_managers group.
intern1 can create files but must not delete others’ files.
auditor must have read-only access.

Your Hackathon Challenge:

Post the exact commands you would use:

Setup: The chown and chmod commands.
Inheritance: The special bit that forces group inheritance.
Safety: The special bit that prevents deletions by non-owners.
Oversight: The exact setfacl command for the auditor.

Bonus: What command shows all permissions, including ACLs?

This one separates theory from real-world skill. Let’s see your architectures.

TudorRaduta

Pulling in a few sharp minds here: @martindxc @Antonis_Bistas @Dyarven @Roldo @JSP @SANJURAJ . Curious to see how you’d solve this.

Architect_005

Hi
We can follow below as mentioned steps for the given challenge.

Members of hr_managers must create, read, and delete files.
sudo mkdir -p /srv/hr-dropbox
sudo chown :hr_managers /srv/hr-dropbox

All new files must automatically inherit the hr_managers group.
sudo chmod g+s /srv/hr-dropbox

intern1 can create files but must not delete others’ files.
sudo setfacl -m u:intern1:rwx /srv/hr-dropbox
sudo setfacl -m d:u:intern1:rwx /srv/hr-dropbox

sudo chmod +t /srv/hr-dropbox

auditor must have read-only access.
sudo setfacl -m user:auditor:rx /srv/hr-dropbox/
sudo setfacl -m d:u:auditor:rx /srv/hr-dropbox

What command shows all permissions, including ACLs?
sudo getfacl /srv/hr-dropbox/

sa_sachin

Love this mini‑hackathon, @TudorRaduta and thanks for the invite.

Below is a clean, layered build of an HR Drop Box at /srv/hr-dropbox that uses standard permissions, special bits, and ACLs exactly as requested.

1) Setup — chown & chmod:

###Create the directory, set ownership to the HR managers group, and give owner/group full control.
# groupadd hr_managers
# useradd -m intern1
# useradd -m auditor

###Create the dropbox directory
#mkdir -p /srv/hr-dropbox

###Owner = root, Group = hr_managers
#chown root:hr_managers /srv/hr-dropbox

###Permissions: rwx for owner & group, none for others as it's a secure folder only for hr so preventing other users.
#chmod 770 /srv/hr-dropbox

2) Inheritance: The special bit that forces group inheritance.

###To ensures every new file/dir created inside automatically has the hr_managers group, for this we will add setgid bit(g+s).
# chmod g+s /srv/hr-dropbox

3) Safety: The special bit that prevents deletions by non-owners.
###For this we need to configure the sticky bit on a directory, This will only allow file owner, the directory owner, or root to delete/rename entries. Even if others have write access to the directory. Eg. this lets intern1 create files but not delete others’ files.So Adding the sticky bit (t)
#chmod +t /srv/hr-dropbox

4) Oversight: The exact setfacl command for the auditor.
### For this give auditor read‑only (and directory traverse) access to current contents and automatically to new ones.
#setfacl -m u:auditor:rx /srv/hr-dropbox

5) ACL for intern1 (can create, but cannot delete others)

###Intern needs to be able to create file and deletion is prevented by the sticky bit. We’ll allow write+execute on the directory (no list permission by default), and inherit for the future.

## Allow intern1 to create (write) and traverse (execute) the directory
#setfacl -m u:intern1:wx /srv/hr-dropbox

## Default ACL so intern’s ability to create continues inside nested subdirs
#setfacl -d -m u:intern1:wx /srv/hr-dropbox

Bonus — Show all permissions (including ACLs)

# See POSIX permissions and full ACLs
getfacl -R /srv/hr-dropbox

# Quick check to see ACL presence (+ shows ACL on ls)
ls -ld /srv/hr-dropbox

SANJURAJ

Thanks for the invite on HR Drop Box Friday Hackathon

These are the steps which based on the scenario using the standard permissions, ACLs and special permissions.

1) Setup — chown & chmod:

root@rhel:~# mkdir /srv/hr-dropbox
root@rhel:~# chown -R root:hr_managers /srv/hr-dropbox

2) Inheritance: The special bit that forces group inheritance.

root@rhel:~# chmod g+ws /srv/hr-dropbox

3) Safety: The special bit that prevents deletions by non-owners.

root@rhel:~# chmod o+wt /srv/hr-dropbox

4) Oversight: The exact setfacl command for the auditor.

root@rhel:~# setfacl -m u:auditor:rX /srv/hr-dropbox
root@rhel:~# setfacl -m d:u:auditor:rX /srv/hr-dropbox (for future files)

Note: For intern1 user in the /srv/hr-dropbox, he can create, delete his own files but since we have the sticky bit set, he must not delete others’ files.

Bonus — Show all permissions (including ACLs)

root@rhel:~# getfacl /srv/hr-dropbox
getfacl: Removing leading '/' from absolute path names
# file: srv/hr-dropbox
# owner: root
# group: hr_managers
# flags: -st
user::rwx
user:auditor:r-x
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:auditor:r-x
default:group::rwx
default:mask::rwx
default:other::rwx

martindxc

As solution was provided above there's nothing for me to add.

Real fun begins when you need to mix applications together. You have one group of "windows only" users, their share is used exclusively within samba, mixed with guest and AD authenticated users. (public/ vs appl/ ).

Second group is accessing the share with scp.

And then you have users who use application, most likely on cellphone, that pushes images to certain shared location (e.g. immich uploading pictures to shared dir).

Doable, but can be source of headache.

Of course FS needs to be subject to regular backups.