Bug #1379
closed
ls crashes printing (some) ACLs
100%
Description
metropolis:~> mdb /bin/ls :r -Val /etc ... 080476c8 libsec.so.1`acl_printacl+9(504, 50, 1, 805487d) 08047738 pentry+0x803(806f348) 08047788 pem+0x181(8095cfc, 80960c0, 1, 0, 1ac, 806b7c0) 08047a78 main+0x1248(3, 8047ab0, 8047ac0, 8047a6c) 08047aa4 _start+0x7d(3, 8047b98, 8047b9b, 8047ba0, 0, 8047ba5)
It seems moderately obvious that the *aclp argument (the first) to acl_printacl is invalid.
I think that my /etc is sufficiently normal that this should be repeatable, though I confess that I don't have a convenient way to view the ACL of the problem file which isn't ls, which of course crashes.
Updated by Rich Lowe almost 12 years ago
- Assignee set to Rich Lowe
- Difficulty changed from Medium to Bite-size
Looks like aclp is not initialized in gstat, so when we hit a symlink (and disable ACL processing, as symlinks can't have ACLs) we're left with whatever was on the stack in aclp, foiling any following aclp != NULL condition).
Updated by Rich Lowe almost 12 years ago
Turns out this isn't as easy to reproduce as I'd hope, though it's consistent on my machine. It seems to be very fussy about where in the global flist you'll be, as well as the contents of the memory from malloc (not, as I'd previously said, the stack).
Updated by Yuri Pankov almost 12 years ago
Reproducible on my system as well:
sirius:yuri:~$ ls -Vl /etc/cron lrwxrwxrwx 1 root root 16 Jun 4 01:53 /etc/cron -> ../usr/sbin/cron Segmentation Fault (core dumped)
Updated by Rich Lowe almost 12 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 80
Thanks Yuri. I'll try to RTI this later today.
Updated by Rich Lowe almost 12 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Resolved in r13434 commit:af0bf36c290c