Bug #1379

ls crashes printing (some) ACLs

Added by Rich Lowe over 9 years ago. Updated over 9 years ago.

cmd - userland programs
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


metropolis:~> mdb /bin/ls
:r -Val /etc
080476c8`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 over 9 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 over 9 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 over 9 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 over 9 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 over 9 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

Resolved in r13434 commit:af0bf36c290c

Also available in: Atom PDF