1

For reasons I can't determine, within the last two days the "man" command stopped working on my linux server (Ubuntu 18.04). When attempting to run man <anything> I end up at a blank instance of vi (presumably because it's using vimpager somewhere in the background)... once I quit out of the vim instance I see the following errors on the console:

lwobker@lwobker-vms:~$ man ls
cat: /tmp/vimpager_4620/cols: Permission denied
cat: /tmp/vimpager_4620/lines: Permission denied
head: cannot open '/tmp/vimpager_4620/stdin' for reading: Permission denied
sed: can't read /tmp/vimpager_4620/stdin: Permission denied
mv: cannot move '/tmp/vimpager_4620/stdin.work' to '/tmp/vimpager_4620/stdin': Permission denied
cat: /tmp/vimpager_4620/stdin: Permission denied
/usr/bin/pager: 242: /usr/bin/pager: cannot open /tmp/vimpager_4620/stdin: Permission denied
/usr/bin/pager: 239: [: Illegal number: 

This happens regardless of whether I'm running at a "regular" user, or if I do sudo man <anything> or if I do sudo bash and run it that way.

Clearly there's a permissions issue somewhere but I'll be damned if I can figure out where. All the /tmp directories mentioned in the error messages are present and have read permissions set, so I can't quite figure out why all these commands are complaining.

lwobker@lwobker-vms:/tmp$ ll vimpager_4234/
total 60
drwx------  2 lwobker lwobker  4096 Nov  8 10:47 ./
drwxrwxrwt 24 root    root    40960 Nov  8 10:56 ../
-rw-r--r--  1 lwobker lwobker    11 Nov  8 10:47 1.vim
-rw-r--r--  1 lwobker lwobker  9664 Nov  8 10:47 stdin
-rw-r--r--  1 lwobker lwobker     0 Nov  8 10:47 stdin.work
2
  • Are you able to create or modify files in that folder directly, with eg. touch /tmp/vimpager_1234/testfile ?
    – JigglyNaga
    Commented Nov 8, 2018 at 16:09
  • Yep... touch, tee, cat, echo - everything works.
    – ljwobker
    Commented Nov 8, 2018 at 18:27

1 Answer 1

1

It turns out that somehow the apparmor profiles for the /usr/bin/man executable were either corrupted or had be overwritten with the profiles from a different release, or something along those lines... so the permission denied warnings were coming from apparmor and not from the filesystem permission checks.

Checking the syslog showed tons of messages like:

audit: type=1400 audit(1541703091.843:4554): apparmor="DENIED" operation="ptrace" profile="/usr/bin/man" pid=8777 comm="ps" requested_mask="trace" denied_mask="trace" peer="/usr/bin/man"

The solution was a nifty tool that I wasn't aware of called aa-logprof, which basically parses the errors from apparmor in your syslog and (interactively) asks if you want to adjust the apparmor profiles to fix the permissions.

1
  • 1
    Oh, and if there's ONE TOOL that I never want to be unable to use again... it's "man" ;-)
    – ljwobker
    Commented Nov 8, 2018 at 19:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .