[Lab 6.3] Is Ubuntu ignoring my facl?

albertgoma

My current setup has 3 bare metal servers with

• Ubuntu 23.10 with kernel 6.5.0-25-generic (minimal install but later unminimized to server)
• openSUSE Tumbleweed 20240313 with kernel 6.7.9-1default
• CentOS Stream release 9 with kernel 5.14.0-427.el9.x86_64

---

To begin with, unlike on openSUSE and CentOS, on Ubuntu I needed to sudo apt install acl.

When I create the file and set its acl on the three of them:

[albert] touch /tmp/file
[albert] setfacl -m u:rocky:rw /tmp/file

The permissions for /tmp are drwxrwxrwt on all of them and the permissions for /tmp/file are:

• -rw-rw-r--+ on openSUSE and CentOS
• -rw-rw----+ on Ubuntu

On openSUSE and CentOS, when I execute getfacl /tmp/file, I get

getfacl: Removing leading '/' from absolute path names
# file: tmp/file
# owner: albert
# group: albert
user::rw-
user:rocky:rw-
group::r--
mask::rw-
other::r--

while on Ubuntu I get

getfacl: Removing leading '/' from absolute path names
# file: tmp/file
# owner: albert
# group: albert
user::rw-
user:rocky:rw-
group::rw-
mask::rw-
other::---

However, when I sudo -s -u rocky and echo "12345" >> /tmp/file, on openSUSE and CentOS it works, but on Ubuntu I get

rocky@ubuntu:~$ echo "12345" >> /tmp/file
bash: /tmp/file: Permission denied

I checked it and ACLs were enabled on the filesystem (ext4). On /etc/fstab the mount options were set to default, and when I checked those defauts

rocky@ubuntu:~$ sudo tune2fs -l /dev/disk/by-id/******
tune2fs 1.47.0 (5-Feb-2023)
Filesystem volume name:   <none>
Last mounted on:          /
... 
Default mount options:    user_xattr acl
...

---

Therefore my question is

What the heck is wrong with Ubuntu?

albertgoma

My Ubuntu's /etc/fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/ubuntu-vg/ubuntu-lv during curtin installation
/dev/disk/by-id/dm-uuid-LVM-********** / ext4 defaults 0 1
# /boot was on /dev/sda2 during curtin installation
/dev/disk/by-uuid/************* /boot ext4 defaults 0 1
/swap.img   none    swap    sw  0   0

albertgoma

Surprisingly the read permission works:

rocky@ubuntu:~$ cat /tmp/file
12345
rocky@ubuntu:~$ echo "aaaaa" >> /tmp/file
bash: /tmp/file: Permission denied

Moving the file to another directory within /tmp as mentioned in this post didn't work either.

luisviveropena

Hi @albertgoma, I did a test on Ubuntu 23.10 and the original solution didn't work (on /tmp/afile). But the workaround I provided on https://forum.linuxfoundation.org/discussion/863781/lab-6-3-file-permissions-issue-first-post-question worked!

So, if you want to keep working the issue, please send me details of the commands you are running, because it worked for me if I put the file on /tmp/test/afile .

Regards,
Luis.

albertgoma

Hi @luisviveropena, thanks for your reply. In my case that workaround didn't. It's great to know on Ubuntu 23.10 it actually did work for you. My intuition now tells me the issue must be related to installing a minimal version of the OS and later unminimizing it (maybe the config files and/or lib dependencies didn't end up being identical to those of the default Ubuntu Server install?) so reinstalling it as Ubuntu Server should, as a last resource, solve the problem.

Of course, as I managed to do the lab on OpenSUSE and CentOS, I moved on with the lessons. But I'm intrigued with this issue, so I'm coming back to it every now and then.

What I learned from my experience is that when things don't work as they should you end up learning more than when they do.

I'll keep this thread updated if I have further findings.

luisviveropena

albertgoma,

Hi @luisviveropena, thanks for your reply. In my case that workaround didn't. It's great to know on >Ubuntu 23.10 it actually did work for you. My intuition now tells me the issue must be related to >installing a minimal version of the OS and later unminimizing it (maybe the config files and/or lib >dependencies didn't end up being identical to those of the default Ubuntu Server install?) so >reinstalling it as Ubuntu Server should, as a last resource, solve the problem.

Oh, that's interesting. You could be able to find some differences between the distros using diff, or perhaps md5sum

What I learned from my experience is that when things don't work as they should you end up learning >more than when they do.

Yep, it's like that.

Many regards,
Luis.