RL8: Why cannot root ls a user home directory?

I am working on an RL8 system logged in as root. When I do this:
[root@vhp3k-06 ~]# ls -l /home/stromasys/*

I see this:
ls: cannot access '/home/stromasys/*': No such file or directory

But, If i use su then I see these files:

[root@vhp3k-06 ~]# su -l stromasys
Last login: Thu Nov 10 14:45:57 EST 2022 from 192.168.216.104 on pts/1
[stromasys@vhp3k-06 ~]$ ls -la
total 16
drwx------. 3 stromasys stromasys  95 Nov 10 12:54 .
drwxr-xr-x. 5 root      root       60 Nov 10 12:40 ..
-rw-------. 1 stromasys stromasys 140 Nov 10 13:00 .bash_history
-rw-r--r--. 1 stromasys stromasys  18 Aug  2 03:41 .bash_logout
-rw-r--r--. 1 stromasys stromasys 141 Aug  2 03:41 .bash_profile
-rw-r--r--. 1 stromasys stromasys 376 Aug  2 03:41 .bashrc
drwx------. 2 stromasys stromasys 114 Nov 10 12:54 .ssh

Further, If I do this as the stromasys user:

[stromasys@vhp3k-06 ~]$ touch touchme
[stromasys@vhp3k-06 ~]$ exit
logout

Then this is observed:

[root@vhp3k-06 ~]# ls -la /home/stromasys/
total 16
drwx------. 3 stromasys stromasys 110 Nov 11 09:29 .
drwxr-xr-x. 5 root      root       60 Nov 10 12:40 ..
-rw-------. 1 stromasys stromasys 166 Nov 11 09:29 .bash_history
-rw-r--r--. 1 stromasys stromasys  18 Aug  2 03:41 .bash_logout
-rw-r--r--. 1 stromasys stromasys 141 Aug  2 03:41 .bash_profile
-rw-r--r--. 1 stromasys stromasys 376 Aug  2 03:41 .bashrc
drwx------. 2 stromasys stromasys 114 Nov 10 12:54 .ssh
-rw-rw-r--. 1 stromasys stromasys   0 Nov 11 09:29 touchme

Why does creating a ordinary file change the behaviour of ls in this instance?

I cannot replicate your problem:

[root@rocky8 ~]# ls -lha /home/ian/
total 16K
drwx------. 2 ian  ian   83 Oct  4 13:42 .
drwxr-xr-x. 3 root root  17 Aug 24 15:47 ..
-rw-------. 1 ian  ian  147 Oct  4 13:42 .bash_history
-rw-r--r--. 1 ian  ian   18 Apr 12  2022 .bash_logout
-rw-r--r--. 1 ian  ian  141 Apr 12  2022 .bash_profile
-rw-r--r--. 1 ian  ian  376 Apr 12  2022 .bashrc

the only thing I can think is perhaps during installation you selected a particular security profile? Or maybe this was enabled later or something? Can you confirm if this was the case or not?

Otherwise, there is simply no reason for root not being able to see those files - just like my example shows. Mine was a basic Rocky install, no security profile selected, selinux enabled.

RL8 is installed as a VM running on top of FreeBSd-12.3.

As far as I can recall I did not do anything other than take the defaults during the install. However, if there were required choices then I cannot remember which ones I selected. It was intended to be a plain vanilla install so there was no specific customization that I performed.

[root@vhp3k-06 ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

If a security policy was chosen during install, in theory the openscap packages should have been installed. Can you confirm this?

rpm -qa | grep -i scap

do you have such packages installed?

It does not appear so:

[root@vhp3k-06 ~]# rpm -qa | grep -i scap
perl-Pod-Escapes-1.07-395.el8.noarch
[root@vhp3k-06 ~]#

The reason you didn’t see anything in your first example is that you only had “.files” in stromasys and “ls -l” won’t show any of those files. If you had used ls -la first time around you would have seen the dot files.

Actually, I did that with the same result. I copied an earlier trial for the example.

[root@vhp3k-06 ~]# ll /home
total 0
drwx------. 2 byrnejb_hll byrnejb_hll 62 Nov  8 12:34 byrnejb_hll
drwx------. 3 stromasys   stromasys   95 Nov 10 12:54 stromasys
drwx------. 2 terminator  terminator  62 Nov  8 12:51 terminator
[root@vhp3k-06 ~]# ll /home/stromasys
total 0
[root@vhp3k-06 ~]# ll /home/stromasys/*
ls: cannot access '/home/stromasys/*': No such file or directory
[root@vhp3k-06 ~]# ls -l /home/stromasys/*
ls: cannot access '/home/stromasys/*': No such file or directory
[root@vhp3k-06 ~]# chmod 744 /home/stromasys
[root@vhp3k-06 ~]# ls -l /home/stromasys/*
ls: cannot access '/home/stromasys/*': No such file or directory
[root@vhp3k-06 ~]# chmod 700 /home/stromasys
[root@vhp3k-06 ~]# ls -la /home/stromasys/*
ls: cannot access '/home/stromasys/*': No such file or directory

I have no idea why it doesn’t work, looks very weird to me. I have a minimal install, and it works properly. Hopefully someone else will jump in and might be able to help, I’m out of ideas. That’s just not normal behaviour.

Thank you for the help. It is not an important thing. I have been away from CentOS since v7 and wondered if something had changed.

Interesting though. Here I created a test directory in /home with a few dot files in it. What seems to through things off is the use of the * character .

[root@t4s ~]# ls -l /home/testuser/*
ls: cannot access '/home/testuser/': No such file or directory
[root@t4s ~]# ls -la /home/testuser/

ls: cannot access ‘/home/testuser/*’: No such file or directory
[root@t4s ~]# ls -la /home/testuser/
total 8
drwxr-xr-x 2 jbk jbk 4096 Nov 11 13:28 .
drwxr-xr-x. 5 root root 4096 Nov 11 13:26 …
-rw-r–r-- 1 jbk jbk 0 Nov 11 13:28 .afile
-rw-r–r-- 1 jbk jbk 0 Nov 11 13:28 .anotherfile
-rw-r–r-- 1 jbk jbk 0 Nov 11 13:28 .ditto

Blockquote

1 Like

You do two different commands and get two different outputs.
That is as it should be.

$ ls
$ ls *
ls: cannot access '*': No such file or directory
$ ls -a
.   .bash_history  .bashrc   .local    .ssh
..  .bash_logout   .emacs.d  .lesshst  .profile
$ ls -a *
ls: cannot access '*': No such file or directory

Remember that shell does do expansion on command-line, before any command it invoked.

In a directory, where there are at most hidden files, the shell cannot expand the * into words.
Therefore, command ls gets the unexpanded /home/stromasys/* as parameter and attempts
to show that verbatim “file”.

You would get that with any non-existent name:

$ ls foo
ls: cannot access 'foo': No such file or directory
$ ls -a foo
ls: cannot access 'foo': No such file or directory

Had you used the same command after creating the file, you would probably got:

[root@vhp3k-06 ~]# ls -la /home/stromasys/*
-rw-rw-r--. 1 stromasys stromasys   0 Nov 11 09:29 touchme
1 Like

I realize that. Please bear in mind that I was trying different approaches to see if I was doing something wrong. The critical instruction and result that led to the experimentation was this:

[root@vhp3k-06 ~]# ls -la /home/stromasys/*
ls: cannot access '/home/stromasys/*': No such file or directory

Please note that both -l and -a are specified and the glob character * follows the path string.

After I manually added a file to that directory the results from ls were as one expects. I am not saying that I did not make a mistake somewhere. But I do not see it.

You can omit the asterisk, and then it works properly. Remember asterisk on it’s own, doesn’t match hidden files.

So it’s clear now after @jbkt23 and @jlehtone explained it. I completely missed it.

Because there are currently only hidden files in the stromasys directory and you need to have shopt -s dotglob set (which is not set by default) in order for bash to expand hidden files.

You’re using a different command to list them here. You’re no longer using a glob (*) to expand the files and so ls is expanding them instead, and the -a switch to ls tells it to show hidden files.

Again, it boils down to the command you’re using to list them. You can see them for the same reasons as in your second example.

It doesn’t, using ls in different ways changes its behavior, though.

1 Like

If your /home is an NFS mount with root_squash enabled, root will not be able to access it.

True, but that was not the issue here. Besides, when root has no access to NFS share, addition of a file does not change that.

What can I say: I cheat!! I simply use Midnight Commander (mc) and it will show you the hidden f files, and the contents… just can’t work on them. Can’t have everything.