weird permission on mandoc.db, fixed, but why?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

weird permission on mandoc.db, fixed, but why?

Peter J. Philipp-3
Hi,

I did something I should not have done.  I wrote a manpage and placed it
in /usr/share/man/man7/ instead of /usr/local/... However when I did
this the permissions on mandoc went screwy I don't know why.

beta# ls -lh /usr/local/man/mandoc.db
-rw-------  1 root  wheel   862K Jan 28 20:56 /usr/local/man/mandoc.db
beta# chmod 644 /usr/local/man/mandoc.db
beta# crontab -l | grep umask
beta# ls -lc /usr/share/man/man7/alphabet.7
-rw-r--r--  1 root  wheel  2845 Jan 28 15:02 /usr/share/man/man7/alphabet.7
beta# umask
022

It also couldn't have been weekly crontab, it runs at 3:30AM, something
else caused the mandoc.db to be rebuilt and inherited a weird umask.

Unfortunately this is all I can give to try to backtrack what happened. 
Ideas for next time to prevent this  or suggestions how this happened
would be nice.

I grepped through the mandoc source and didn't find a mention of umask.

Regards,

-peter

Reply | Threaded
Open this post in threaded view
|

Re: weird permission on mandoc.db, fixed, but why?

Peter J. Philipp-3
Sorry I'm answering my own mail.  At that time the mandoc.db was
updated, I installed some packages, nginx, php72, could having a wrong
umask in my shell have caused this?

Regards,

-peter

On 1/30/19 7:49 PM, Peter J. Philipp wrote:

> Hi,
>
> I did something I should not have done.  I wrote a manpage and placed
> it in /usr/share/man/man7/ instead of /usr/local/... However when I
> did this the permissions on mandoc went screwy I don't know why.
>
> beta# ls -lh /usr/local/man/mandoc.db
> -rw-------  1 root  wheel   862K Jan 28 20:56 /usr/local/man/mandoc.db
> beta# chmod 644 /usr/local/man/mandoc.db
> beta# crontab -l | grep umask
> beta# ls -lc /usr/share/man/man7/alphabet.7
> -rw-r--r--  1 root  wheel  2845 Jan 28 15:02
> /usr/share/man/man7/alphabet.7
> beta# umask
> 022
>
> It also couldn't have been weekly crontab, it runs at 3:30AM,
> something else caused the mandoc.db to be rebuilt and inherited a
> weird umask.
>
> Unfortunately this is all I can give to try to backtrack what
> happened.  Ideas for next time to prevent this  or suggestions how
> this happened would be nice.
>
> I grepped through the mandoc source and didn't find a mention of umask.
>
> Regards,
>
> -peter

Reply | Threaded
Open this post in threaded view
|

Re: weird permission on mandoc.db, fixed, but why?

Ingo Schwarze
Hi Peter,

Cc:'ing espie@ because i'm asking a question about pkg_add(1) at the end.

Peter J. Philipp wrote on Wed, Jan 30, 2019 at 07:56:26PM +0100:
> On 1/30/19 7:49 PM, Peter J. Philipp wrote:

>> I did something I should not have done.
>> I wrote a manpage and placed it in /usr/share/man/man7/
>> instead of /usr/local/...

From a mandoc perspective, there is nothing wrong with manually
adding manual pages to any manual page directories.  The man(1)
program will find them right away (of course only under the file name,
not under additional names contained in the NAME section), and running
makewhatis(8) is the right way to update the databases such that
apropos(1) finds them, too.

From a system administration perspective, your private pages belong
in neither /usr/share/ nor /usr/local/.
The base system owns /usr/share/, and pkg_add(1) owns /usr/local/.  
So if you want to install stuff manually, you should invent a
non-standard path outside /usr/share/ and /usr/local/, and then the
manpath directive in man.conf(5) is your friend.

>> However when I did this the permissions on mandoc went screwy
>> I don't know why.
>>
>> beta# ls -lh /usr/local/man/mandoc.db
>> -rw------- 1 root wheel 862K Jan 28 20:56 /usr/local/man/mandoc.db
[...]
>> something else caused the mandoc.db to be rebuilt and inherited a
>> weird umask.
[...]
>> I grepped through the mandoc source and didn't find a mention of umask.

Right, makewhatis(8) uses whatever umask it inherits.  So if root
runs makewhatis(8) with a wrong umask, the mandoc.db(5) will end up
with wrong permissions.

> Sorry I'm answering my own mail.  At that time the mandoc.db was
> updated, I installed some packages, nginx, php72, could having a wrong
> umask in my shell have caused this?

That's a question about pkg_add(1).  Simple experimentation shows that
just like makewhatis(8), pkg_add(1) uses whatever umask it inherits.
For most files pkg_add creates, that's fine because permissions are
explicitly set according to packing lists.  But makewhatis(8) is
just forked and executed.

Marc, should pkg_add(1) explicitly chmod 644 mandoc.db(5) after
running makewhatis(8)?  Or should makewhatis(8) itself do an
explicit chmod 644 after creating a new mandoc.db(5) file?
I don't particularly like the latter because in principle,
secretive organizations might have secret manual page hierarchies
that only certain groups of users can read.  That certainly doesn't
apply to /usr/local/man/, though, so possibly pkg_add(1) should
take care of it.  Or is pkg_add(1) supposed to support secret
software installations that only certain users can see?

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: weird permission on mandoc.db, fixed, but why?

Stuart Henderson
On 2019-01-30, Ingo Schwarze <[hidden email]> wrote:
> That's a question about pkg_add(1).  Simple experimentation shows that
> just like makewhatis(8), pkg_add(1) uses whatever umask it inherits.
> For most files pkg_add creates, that's fine because permissions are
> explicitly set according to packing lists.  But makewhatis(8) is
> just forked and executed.

Similar has come up before - as well as mandoc.db, @sample'd files and
files in /var/db/pkg are affected by umask - the former sometimes resulting
in an unusable package installation.
>