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
Improve this question
2
  • Are you able to create or modify files in that folder directly, with eg. touch /tmp/vimpager_1234/testfile ? Commented Nov 8, 2018 at 16:09
  • Yep... touch, tee, cat, echo - everything works. Commented Nov 8, 2018 at 18:27

1 Answer 1

Reset to default
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.

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

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.