R-x And R-x.

Home » CentOS » R-x And R-x.
CentOS 26 Comments

Dear All,

I’m currently troubleshooting NetworkManger scripts.

I see a difference in machine A :

drwxr-xr-x 2 root root 4096 apr 24 16:33 . drwxr-xr-x 5 root root 4096 jan 9 12:13 ..
-rwxr-xr-x 1 root root 175 jan 9 12:13 00-netreport
-rwxr-xr-x 1 root root 335 okt 22 2012 04-iscsi
-rwxr-xr-x 1 root root 345 jan 9 12:13 05-netfs
-rwxr-xr-x 1 root root 926 sep 25 2012 10-dhclient
-rwxr-xr-x 1 root root 301 apr 24 15:58 20-backuplauncher
-rwxr-xr-x 1 root root 220 jun 22 2012 yum-NetworkManager-dispatcher

and machine B:

drwxr-xr-x. 2 root root 4096 apr 24 16:34 . drwxr-xr-x. 5 root root 4096 apr 23 12:06 ..
-rwxr-xr-x. 1 root root 175 jan 9 12:13 00-netreport
-rwxr-xr-x. 1 root root 345 jan 9 12:13 05-netfs
-rwxr-xr-x. 1 root root 926 sep 25 2012 10-dhclient
-rwxr-xr-x. 1 root root 326 apr 23 13:42 15-nfslauncher
-rwxr-xr-x. 1 root root 307 apr 24 16:10 20-backuplauncher
-rwxr-xr-x. 1 root root 220 jun 22 2012 yum-NetworkManager-dispatcher

the difference being -rwxr-xr-x and -rwxr-xr-x.

so with or without a dot (.)

Does that mean anything?

Thanks for any advise on this.

Greetings, J.

Opensource Software is the future.

26 thoughts on - R-x And R-x.

  • Hi Johan,

    From “info coreutils”, section 10.1.2 (What information is listed):

    Following the file mode bits is a single character that specifies
    whether an alternate access method such as an access control list
    applies to the file. When the character following the file mode
    bits is a space, there is no alternate access method. When it is
    a printing character, then there is such a method.

    GNU `ls’ uses a `.’ character to indicate a file with an SELinux
    security context, but no other alternate access method.

    A file with any other combination of alternate access methods is
    marked with a `+’ character.

    My first guess would be that Machine A has SELinux disabled, but Machine B has (or had at some point) SELinux enabled.


  • The . means the file has an access list with SELinux. You could try disabling SELinux on machine B and seeing if that fixes the issue.

  • Dear All,

    thanks for the responses.

    Indeed, on machine A, Selinux is disabled.

    -bash-4.1# selinuxenabled && echo enabled || echo disabled disabled

    and on machine B, it’s enabled.

    I will test the script again on B with Selinux disabled.

    Greetings, J.

    Op 24-04-13 18:06, Ian Forde schreef:

  • Disabling SELinux is not going to fix your problem. Since the field is just showing you that you have extended attibutes assigned to yr files.

    Why not just script around it.

    ls -l | sed ‘s/\. / /g’

    Would replace all “. ” from your output.

  • Johan Vermeulen wrote:
    ARGH. Unless you move it to permissive, at least, you’re in for a world of hurt until you fix all the stuff. If you’ve got time, touch /.autorelabel and reboot. And wait, for a while…..


  • Because that would be too easy and people absolutely love to shoot themselves in the face by disabling selinux. Because it is, as we all know, ridiculously hard to manage.



    Did I forget a tag?

  • John R. Dennison wrote:

    Don’t get me started. I’m fighting it regularly. For example, SELinux is preventing /usr/bin/perl from getattr access on the file
    /sys/devices/system/node/node0/meminfo. For complete SELinux messages.

    And yes, I did post a few things to the selinux list….


  • Op 24-04-13 22:53, m.roth@5-cent.us schreef:

    Dear All,

    thanks again for the reactions.

    This is the NetworkManager script I’m trying to use:


  • Although i don’t use NetworkManager I suspect it runs in some kind of context such as NetworkManager_t …

    It’s unlikely that context will have permission to read/write/traverse/etc home_t (which is the file context for user home directories).

    I suspect there is no boolean to allow what you want so if you want selinux enabled you’ll need to build a module – look at audit2allow and the various guides surrounding that for how to use it …

    First thing to check will be run in Permissive and then look at
    `audit2allow -a` to see exactly what process is trying to do what operation
    … and then from there you can create the module to allow what you want.

  • and you wonder why people give up on selinux. ‘sorry, boss.. I’ll get that TPC report out just soon as I debug this selinux audit module…’

  • :-)
    In this context ” I ‘ run your backup when….

    verzonden m.b.v Android vandaar de beknoptheid.

    John R Pierce schreef:

  • Two things: unless this is a laptop, shut down NetworkManager – there is
    *no* use for it in a wired environment. And edit
    /etc/sysconfig/network-scripts/ifcfg-eth? so that they say NMCONTROLLED=”no”. network works just fine, and doesn’t introduce the overhead.

    Second, check the selinux contexts – ll -Z, and if setroubleshoot isn’t installed, you should do so. Running the sealert messages that show in
    /var/log/messages will frequently (NOT always) help you fix the context issues.


  • See if chcon -t bin_t /usr/bin/rsync solves your problem.

    I believe that NetworkManager runs its helper scripts as initrc_t which is an unconfined domains, except that when it executes rsync, it transition to a confined rsync server domain(rsync_t). Changing the context to bin_t would eliminate the transition and leave rsync running in initrc_t.


  • Op 25-04-13 14:49, Daniel J Walsh schreef:

    Dear All,

    thanks for the advise.

    Yes, it concerns a laptop, if not I would indeed turn of NetworkManager.

    I am in the process of converting our last older OpenSuse-laptop to CentOS6.4. Now all 26 of our Linux laptops ( 4 sadly run Windows ) will be on CentOS.

    I often hear people say they would never run CentOS on laptops, but I
    think it works great.

    Also today I will replace the last of 4 machines of our admin Department to CentOS. ( One will remain on Windows ) .

    I just needed to share that with somebody.

    Tomorrow I will test the advise that I kindly received here.

    Greetings, J.

  • What’s the logic behind rsync having its own context here? If it isn’t running as a standalone daemon (and maybe even if it is)
    shouldn’t it have the permissions of whoever starts it?

  • Johan Vermeulen wrote:

    Ah! And selinux. Have you encrypted the h/d’s?

    I think we all understand that one, and I think a round of applause is due
    – congratulations.


  • Op 25-04-13 16:33, m.roth@5-cent.us schreef:

    you know, I did argue that with my boss but he was against it. Guess he didn’t want to type 2 passwords. So the only encrypted laptop is my own. But my boss was sorry when his got stolen a few months ago.

    thank you thank you

  • a coworker had his encrypted (Windows, using Bitlocker) laptop suffer some HD issue such that it couldn’t boot last week. noone in the windows-centric IT support group at his site could figure out how to repair or recover it, so he ended up having to nuke and rebuild and wasn’t able to recover any of his files.

    security is a 2 edged sword.

  • At least in an ‘always connected’ scenario DHCP should work without NetworkManager. You might need it to notice cable disconnects and reconnection on different networks.

  • John R Pierce wrote:

    Dunno if it does, but network certainly does. I would expect dhclient to be installed by default, and so it’s merely a matter of making sure that it says BOOTPROTO=”dhcp” in


  • Op 25-04-13 19:41, m.roth@5-cent.us schreef:

    Dear All,

    I finally tested this further ( in the mean time I did NOT disable any selinuxes but worked with cron ) :

    #chcon -t bin_t /usr/bin/rsync


    chcon : change file SELinux security context

    bin_t :

    # Using the type statement to declare a type of bin_t, where
    # bin_t is used to identify a file as an ordinary program type.

    Thanks all of you to help me move on WITH SElinux.

    greetings, J.

  • Johan Vermeulen wrote:

    Warning: you may have needed to read further: a chcon doesn’t last through a reboot. To make that permanent, you need to do:
    semanage fcontext -a -t bin_t /usr/bin/rsync

    You can make sure that took effect with restorecon -v /usr/bin/rsync


  • It does last through a reboot but not a relabel. Which is why the semanage fcontext is important.