Effective permissions and long group names - getfacl: malloc(): memory corruption

[Helge Willum Thingvad]

I have found a combination of ACLs that, when set on a file on an Active Directory joined Ubuntu 10.04 server, will crash the getfacl program upon reading the ACL entries.

The crash appears under the following conditions:
1) getfacl is about to list effective permissions (i.e. limited by mask) for at least two ACL entries.
2) At least one of these entries has a user/group name longer than 32 characters.
3) The output of getfacl is not redirected nor piped to another program/file.

Normally, user/group names longer than 32 characters are prevented from being created on the local system, but they are possible when using central authentication tools such as Centrify DirectControl and Likewise Open.

The crash happens when effective permissions are to be listed, and only when the output of getfacl is written directly to terminal.
Running the test on a separate, non-AD joined host, using regular local users and groups of maximum 32 characters, does not yield any errors.

I have tested and confirmed this bug on two independent systems, both running Ubuntu 10.04 Server, with one using CentrifyDC Express 4.4.3 for AD integration and the other one using Likewise-Open 6.

=== HOW TO REPRODUCE ===
Since the bug does not appear when using locally valid names, it may be required to install centrifydc, likewise-open or another tool in order to create a test environment with user/group names longer than 32 characters. Perhaps LDAP can be used too?

This example uses Centrify DirectControl 4.4.3 Express for AD integration.

mkdir testdir
touch testdir/testfile
setfacl -Rd -m user:<email address hidden>:rwx -m group:<email address hidden>:rwx testdir/
setfacl -Rn -m user:<email address hidden>:rwx -m group:<email address hidden>:rwx testdir/
getfacl testdir # crash, getfacl_testdir_noredirect_crash.log
getfacl testdir > getfacl_testdir_redirect_nocrash.log
getfacl testdir/testfile # crash, getfacl_testfile_noredirect_crash.log
getfacl testdir/testfile > getfacl_testfile_redirect_nocrash.log

=== ATTACHED LOGS ===
getfacl_testdir_noredirect_crash.log (copied from terminal)
getfacl_testdir_redirect_nocrash.log (redirected to log file)
getfacl_testfile_noredirect_crash.log (copied from terminal)
getfacl_testfile_redirect_nocrash.log (redirected to log file)

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: acl 2.2.49-2
ProcVersionSignature: Ubuntu 2.6.32-36.79-server 2.6.32.46+drm33.20
Uname: Linux 2.6.32-36-server x86_64
Architecture: amd64
Date: Mon Dec 5 14:43:30 2011
InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release amd64 (20100427)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_DK.UTF-8
 SHELL=/bin/bash
SourcePackage: acl

[Helge Willum Thingvad (helgesdk)]

I forgot to mention that I had setgid enabled on the parent directory (chmod g+s). Anyway, setting bit is not required to reproduce the bug.

CORRECTION: This bug also affects systems that use Likewise-Open 6.

Still, it only appears with certain combinations of user and group names.
I am not sure just yet what triggers the error, but these commands trigger the same thing (now, in a directory without setgid):

mkdir testdir
chown :CIVIL\\vhost_arch-civil-aau-dk_full testdir/
setfacl -Rd -m user:<email address hidden>:rwx -m group:CIVIL\\vhost_arch-civil-aau-dk_full:rwx testdir/
setfacl -Rn -m user:<email address hidden>:rwx -m group:CIVIL\\vhost_arch-civil-aau-dk_full:rwx testdir/
getfacl testdir/

Now testing on a server with Likewise-Open (using "DOMAIN\\name" format), this is the expected result:
------------
# file: testdir/
# owner: root
# group: CIVIL\134vhost_arch-civil-aau-dk_full
user::rwx
user:CIVIL\134phk:rwx #effective:r-x
group::r-x
group:CIVIL\134vhost_arch-civil-aau-dk_full:rwx #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:user:CIVIL\134phk:rwx
default:group::r-x
default:group:CIVIL\134vhost_arch-civil-aau-dk_full:rwx
default:mask::rwx
default:other::r-x
------------

This is the output on terminal (without redirection/piping):
------------
# file: testdir/
# owner: root
# group: CIVIL\134vhost_arch-civil-aau-dk_full
*** glibc detected *** getfacl: corrupted double-linked list: 0x00000000007577e0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x775b6)[0x7f20a74f15b6]
/lib/libc.so.6(+0x7ddbb)[0x7f20a74f7dbb]
/lib/libc.so.6(realloc+0xf0)[0x7f20a74f80b0]
/lib/libacl.so.1(+0x3e46)[0x7f20a7a05e46]
getfacl[0x402a2c]
getfacl[0x4032f4]
getfacl(walk_tree+0x8b)[0x40386b]
getfacl[0x401df5]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f20a7498c4d]
getfacl[0x401859]
======= Memory map: ========
00400000-00405000 r-xp 00000000 fb:02 537184 /usr/bin/getfacl
00604000-00605000 r--p 00004000 fb:02 537184 /usr/bin/getfacl
00605000-00606000 rw-p 00005000 fb:02 537184 /usr/bin/getfacl
0074c000-0076d000 rw-p 00000000 00:00 0 [heap]
7f20a0000000-7f20a0021000 rw-p 00000000 00:00 0
7f20a0021000-7f20a4000000 ---p 00000000 00:00 0
7f20a57b8000-7f20a57ce000 r-xp 00000000 fb:02 522011 /lib/libgcc_s.so.1
7f20a57ce000-7f20a59cd000 ---p 00016000 fb:02 522011 /lib/libgcc_s.so.1
7f20a59cd000-7f20a59ce000 r--p 00015000 fb:02 522011 /lib/libgcc_s.so.1
7f20a59ce000-7f20a59cf000 rw-p 00016000 fb:02 522011 /lib/libgcc_s.so.1
7f20a59cf000-7f20a59e7000 r-xp 00000000 fb:02 521878 /lib/libpthread-2.11.1.so
7f20a59e7000-7f20a5be6000 ---p 00018000 fb:02 521878 /lib/libpthread-2.11.1.so
7f20a5be6000-7f20a5be7000 r--p 00017000 fb:02 521878 /lib/libpthread-2.11.1.so
7f20a5be7000-7f20a5be8000 rw-p 00018000 fb:02 521878 /lib/libpthread-2.11.1.so
7f20a5be8000-7f20a5bec000 rw-p 00000000 00:00 0
7f20a5bec000-7f20a5bf3000 r-xp 00000000 fb:02 521881 /lib/librt-2.11.1.so
7f20a5bf3000-7...

[Helge Willum Thingvad (helgesdk)]

Here's the same error using Likewise-Open 6 for AD integration.

[Helge Willum Thingvad (helgesdk)]

MAJOR CLUE:
The crash only happens on files where the effective permissions are limited by the mask.
Using the option --no-effective, getfacl no longer crashes.

Oh, and using a shorter user/group names (still containing "unusual" characters) does not result in a crash.

So...

It seems that the conditions for triggering this bug is:
- getfacl is outputting to an interactive terminal (no pipes or redirects)
- long user or group names are present in the ACL
- the "#effective:..." string is to be outputted along with a long user/group entry

This has been testing on two separate systems using different solutions for Active Directory integration.

[Helge Willum Thingvad (helgesdk)]

I downloaded the source for package acl, disabled gcc compiler optimization (-O0), installed libc6-dbg, compiled the acl package and ran getfacl through gdb.

LD_LIBRARY_PATH=/root/acl/acl-2.2.49/libacl/.libs/ gdb /root/acl/acl-2.2.49/getfacl/.libs/getfacl
set args testdir/
run
bt full
bt

(see attached log)

[dino99 (9d9)]

This version has expired