unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* umask/permissions on new files created via notmuch-insert(1) ?
@ 2018-02-04 19:25 Daniel Kahn Gillmor
  2018-02-04 19:34 ` Gaute Hope
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Kahn Gillmor @ 2018-02-04 19:25 UTC (permalink / raw)
  To: Notmuch Mail

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

during some maintenance work today, bremner and i noticed that message
delivery via "notmuch insert" creates files that are stricter than the
umask.

using notmuch 0.23.6, with umask 027, "notmuch insert" created files
with mode 0600.  i would have expected 0640.

using strace, i don't see notmuch invoking any system calls to umask()
or chmod() so i'm not sure how these permissions are getting set in the
first place.

is there a reason that "notmuch insert" should be stricter than the
umask?  does this ring any bells for people?

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: umask/permissions on new files created via notmuch-insert(1) ?
  2018-02-04 19:25 umask/permissions on new files created via notmuch-insert(1) ? Daniel Kahn Gillmor
@ 2018-02-04 19:34 ` Gaute Hope
  2018-02-04 20:59   ` Daniel Kahn Gillmor
  0 siblings, 1 reply; 3+ messages in thread
From: Gaute Hope @ 2018-02-04 19:34 UTC (permalink / raw)
  To: Daniel Kahn Gillmor, Notmuch Mail

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Daniel Kahn Gillmor writes on februar 4, 2018 20:25:
> is there a reason that "notmuch insert" should be stricter than the
> umask?  does this ring any bells for people?

Are you asking why it is or why it should? If former; maybe because of 
line 230 in notmuch-insert.c ?

Regards, Gaute


[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: umask/permissions on new files created via notmuch-insert(1) ?
  2018-02-04 19:34 ` Gaute Hope
@ 2018-02-04 20:59   ` Daniel Kahn Gillmor
  0 siblings, 0 replies; 3+ messages in thread
From: Daniel Kahn Gillmor @ 2018-02-04 20:59 UTC (permalink / raw)
  To: Gaute Hope, Notmuch Mail

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Sun 2018-02-04 20:34:09 +0100, Gaute Hope wrote:
> Daniel Kahn Gillmor writes on februar 4, 2018 20:25:
>> is there a reason that "notmuch insert" should be stricter than the
>> umask?  does this ring any bells for people?
>
> Are you asking why it is or why it should? If former; maybe because of 
> line 230 in notmuch-insert.c ?

yep, that's definitely the cause of it, but looking through the git
history, it seems to have no clear justification.

do other LDA programs behave this way?  is there a reason to not 0666 or
0644 ?  seems like the umask is where people should be making these
choices, and mail being delivered doesn't necessarily need this kind of
lockdown.

we're running into this when looking at a mailing list archiver -- i
want messages to be delivered via "notmuch insert" as the mailbox owner.
but the mailbox viewer is going to be a different user, and they need
read-only access to the archive.  instead, they're completely locked
out.

am i missing something?

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-02-04 21:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-04 19:25 umask/permissions on new files created via notmuch-insert(1) ? Daniel Kahn Gillmor
2018-02-04 19:34 ` Gaute Hope
2018-02-04 20:59   ` Daniel Kahn Gillmor

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).