Dovecot correct ownership for logs

Post by Richard
Maybe someone here knows how the ownership of these files for Dovecot needs
to be in order to work, as various distributions of Dovecot packages seem
I'd like Dovecot not to log into syslog, but to dedicated files. Therefore
I've created the directory /var/log/dovecot and told dovecot in
10-logging.conf to log info, debug and error messages to separate files.

-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log
-rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log
-rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log
So why is Dovecot complaining?

:-)

Post by Richard
I only see processes owned by root, dovecot,
dovenull and user processes of dovecot. And dovenull seems to be not
relevant for this.

Reread
} May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=<***@domain.de>,
} } open log file /var/log/dovecot/error.log: Permission denied )

Note postfix

Post by Richard
Best
Richard

Groeten
Geert Stappers

--
Silence is hard to parse

Greg Wooledge

2024-05-13 20:30:01 UTC

-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log
-rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log
-rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log

The first two things that come to mind are AppArmor, and systemd unit
files.

Check to see whether there's an AppArmor profile for this program, or
any lines from AppArmor in dmesg.

If that's not it, look at the systemd unit file(s) that start the
dovecot service(s), if there are any, and see if they're using any of
the directives that restrict the locations the program can access.

Richard

2024-05-14 11:20:01 UTC

AppArmor complaints would be shown in journalctl too. But dmseg doesn't
show anything either. Just switched dovecot back to these log files, waited
for the error message, yet dmesg doesn't have anything new since yesterday.
Systemd was also my guess as it was originally set to ProtectSystem=full
for dovecot.service, but reducing that to yes didn't change anything.

These are the in the Service block of the service, maybe you see anything
that could be a reason too:
[Service]
Type=notify
ExecStart=/usr/sbin/dovecot -F
ExecReload=/usr/bin/doveadm reload
ExecStop=/usr/bin/doveadm stop
PrivateTmp=true
NonBlocking=yes
ProtectSystem=yes
ProtectHome=no
PrivateDevices=true
Restart=on-failure

Best
Richard

Post by Geert Stappers
May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=<

relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0,

status=deferred

Post by Geert Stappers

net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied

Can't

Post by Geert Stappers

open log file /var/log/dovecot/error.log: Permission denied )

-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log
-rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log
-rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log

The first two things that come to mind are AppArmor, and systemd unit
files.
Check to see whether there's an AppArmor profile for this program, or
any lines from AppArmor in dmesg.
If that's not it, look at the systemd unit file(s) that start the
dovecot service(s), if there are any, and see if they're using any of
the directives that restrict the locations the program can access.

jeremy ardley

2024-05-13 22:50:01 UTC

Post by Richard
Maybe someone here knows how the ownership of these files for Dovecot
needs to be in order to work, as various distributions of Dovecot
I'd like Dovecot not to log into syslog, but to dedicated files.
Therefore I've created the directory /var/log/dovecot and told dovecot
in 10-logging.conf to log info, debug and error messages to separate

A possible cause of problems between postfix and dovecot is that postfix
usuallly runs chroot so the file tree it sees is not the same as the one
the rest of the system sees.

Richard

2024-05-14 11:20:01 UTC

But why should it cause issues? I set the logging in dovecot's conf.d, so
I'd expect dovecot to write these logs, not postfix as it has its own
settings.

Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley <

Post by jeremy ardley

A possible cause of problems between postfix and dovecot is that postfix
usuallly runs chroot so the file tree it sees is not the same as the one
the rest of the system sees.

jeremy ardley

2024-05-14 11:40:01 UTC

But why should it cause issues? I set the logging in dovecot's conf.d,
so I'd expect dovecot to write these logs, not postfix as it has its
own settings.
Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley

Post by Richard
Maybe someone here knows how the ownership of these files for

Dovecot

Post by Richard
needs to be in order to work, as various distributions of Dovecot
I'd like Dovecot not to log into syslog, but to dedicated files.
Therefore I've created the directory /var/log/dovecot and told

dovecot

Post by Richard
in 10-logging.conf to log info, debug and error messages to

separate
A possible cause of problems between postfix and dovecot is that postfix
usuallly runs chroot so the file tree it sees is not the same as the one
the rest of the system sees.

Postfix is chrooted (usuallly) to /var/spool/postfix

If postfix complains about /var/log/dovecot it's actually complaining
about /var/spool/postfix/var/log/dovecot

I would check that file/directory and how dovecot and postfix interact
with it.

Greg Wooledge

2024-05-14 11:50:02 UTC

Post by jeremy ardley
Postfix is chrooted (usuallly) to /var/spool/postfix

If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.

I could imagine the Postfix SMTP sending/receiving and queue processing
programs being chrooted, but the LDA probably isn't. Or at least not
chrooted to /var/spool/postfix.

Richard

2024-05-14 12:00:01 UTC

For us the situation is even a bit stranger. The inboxes are located in
neither location, but in /maildirs/username/ (no idea why it was set up
that way, but it's a dedicated mail server where the user's don't have
their own home directory). /var/mail is empty.

Post by jeremy ardley
Postfix is chrooted (usuallly) to /var/spool/postfix

If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.
I could imagine the Postfix SMTP sending/receiving and queue processing
programs being chrooted, but the LDA probably isn't. Or at least not
chrooted to /var/spool/postfix.

Richard

2024-05-14 13:20:01 UTC

"Top posting" (writing the answer above the text that's being replied to)
is literally industry standard behavior.

Also, I don't think you've really cleared out any confusion. Now, how
exactly can dovecot log to /var/log/dovecot/ without (postfix) throwing
errors? Because it clearly is for 2 out of 3 files as visible from the file
sizes in my original post. Only the debug file is empty, but maybe nothing
relevant enough has been found yet. There are entries from master,
imap, imap-login, managesieve-login, anvil and various other processes in
info and error. But the error messages from postfix still appear, also
seemingly at least vastly slowing down emails being delivered to the users,
if not bringing that to a complete halt. Only after commenting out these
locations in 10-logging.conf the mails show up for the users.

Am Di., 14. Mai 2024 um 14:54 Uhr schrieb Henning Follmann <

Please don't top post! It is a pain to follow a thread if you do.

Am Di., 14. Mai 2024 um 13:45 Uhr schrieb Greg Wooledge <

Post by jeremy ardley
Postfix is chrooted (usuallly) to /var/spool/postfix

If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.

Usually the local delivery is done by a local agent (procmail, dovecot's
lmtp daemon). These do not run chrooted.

Post by Greg Wooledge
I could imagine the Postfix SMTP sending/receiving and queue processing
programs being chrooted, but the LDA probably isn't. Or at least not
chrooted to /var/spool/postfix.

[fixed top posting]

This is a common dovecot setup.
lmtp provides a unix socket into postfix chroot environment. This process
usually runs as postfix user so the socket is owned by postfix. But it uses
the dovecot logging configuration.
Having the maildirs in a dedicated directory makes it easy to have a
dedicated drive just for the mailboxes. This makes adapting to growth much
simpler.
-H
--

Richard

2024-05-14 13:30:02 UTC

And you think you're important enough to change that setting for a whole
mailing account? You're funny.

On Tue, 14 May 2024 15:11:16 +0200
Hello Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being replied
to) is literally industry standard behavior.

This 'literally' isn't industry.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Is she really going out with him?
New Rose - The Damned

Loris Bennett

2024-05-14 14:00:01 UTC

Hi Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being replied
to) is literally industry standard behavior.

Can you provide a link to the standard you are referring to?

Assuming such a standard exists, how would it apply to this newsgroup?

[snip (51 lines)]

Cheers,

Loris

--
This signature is currently under constuction.

Richard

2024-05-14 14:10:01 UTC

Just because something isn't an official ISO standard doesn't mean it's not
standard behavior. And how it relates to this mailing list? It's called a
setting.

Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett <

Post by Loris Bennett
Hi Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being replied
to) is literally industry standard behavior.

Can you provide a link to the standard you are referring to?
Assuming such a standard exists, how would it apply to this newsgroup?
[snip (51 lines)]
Cheers,
Loris
--
This signature is currently under constuction.

gene heskett

2024-05-14 15:00:01 UTC

Post by Richard
Just because something isn't an official ISO standard doesn't mean it's
not standard behavior. And how it relates to this mailing list? It's
called a setting.

No its not, its your refusal to use the down arrow in your reply editor
to put your reply after the question. It really is that simple. If your
choice of email agents cannot do that, its time to switch to an agent
that can. There are dozens of them.

Post by Richard
Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett
Hi Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being replied
to) is literally industry standard behavior.

Cheers, Gene Heskett, CET.

--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

Richard

2024-05-14 15:10:03 UTC

You really must think of yourself as being the epitome of human creation. I
don't see any use in continuing this nonsense. If you don't have anything
relevant to say, this case is closed for me.

Post by gene heskett

Post by Richard
Just because something isn't an official ISO standard doesn't mean it's
not standard behavior. And how it relates to this mailing list? It's
called a setting.

Post by Richard
Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett
Hi Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being

replied

Post by Richard
to) is literally industry standard behavior.

Can you provide a link to the standard you are referring to?
Assuming such a standard exists, how would it apply to this

newsgroup?

Post by Richard
[snip (51 lines)]
Cheers,
Loris
--
This signature is currently under constuction.

Cheers, Gene Heskett, CET.
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

Jeffrey Walton

2024-05-14 19:00:01 UTC

Post by Richard
You really must think of yourself as being the epitome of human creation.
I don't see any use in continuing this nonsense. If you don't have anything
relevant to say, this case is closed for me.

Who are you talking about? There are two people in the reply below.

Jeff

Post by Richard
Am Di., 14. Mai 2024 um 16:55 Uhr schrieb gene heskett <

Post by gene heskett

Post by Richard
Just because something isn't an official ISO standard doesn't mean it's
not standard behavior. And how it relates to this mailing list? It's
called a setting.

Post by Richard
Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett
Hi Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being

replied

Post by Richard
to) is literally industry standard behavior.

Can you provide a link to the standard you are referring to?
Assuming such a standard exists, how would it apply to this

newsgroup?

Post by Richard
[snip (51 lines)]
Cheers,
Loris

Cheers, Gene Heskett, CET.

Larry Martell

2024-05-14 22:30:01 UTC

Post by Jeffrey Walton

Who are you talking about? There are two people in the reply below.

Gene IS the epitome of human creation.

Post by Jeffrey Walton

Post by Richard
Am Di., 14. Mai 2024 um 16:55 Uhr schrieb gene heskett <

Post by gene heskett

Post by Richard
Just because something isn't an official ISO standard doesn't mean

it's

Post by Richard
not standard behavior. And how it relates to this mailing list? It's
called a setting.

Post by Richard
Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett
Hi Richard,

Post by Richard
"Top posting" (writing the answer above the text that's being

replied

Post by Richard
to) is literally industry standard behavior.

Can you provide a link to the standard you are referring to?
Assuming such a standard exists, how would it apply to this

newsgroup?

Post by Richard
[snip (51 lines)]
Cheers,
Loris

Cheers, Gene Heskett, CET.

f***@protonmail.com

2024-05-14 17:10:02 UTC

how many times has this top post crap been dug up
don't y'all have any thing better to do
i know
how about some real debian issues

Greg Wooledge

2024-05-14 17:50:01 UTC

Post by f***@protonmail.com
how many times has this top post crap been dug up
don't y'all have any thing better to do

It's never going to stop. We have a clash of two cultures here.

The first culture are Unix users who grew up with Internet email and
Usenet news. For people in this culture, there is a well-defined set
of "netiquette" rules -- plain text messages, inline quoting with "> "
citation characters, lines limited to ~72 characters, etc.

For users in this first group, email is often read and composed on a
terminal, or a terminal emulator. Characters are displayed in a
fixed-width font. ASCII art is possible, albeit frowned upon as
juvenile.

The second culture are Windows users who grew up with Microsoft products
in their school or workplace. In this culture, top-posting is the norm,
and inline quoting is nigh impossible. Messages are often sent in either
HTML or markdown format. Whole paragraphs are presented as single lines.
Explicit line breaks are only used between paragraphs.

Users in this second group typically use Microsoft Outlook, or a
web-based mail user agent in a graphical environment. Fonts are
variable-width, and any ASCII art or tables will not align properly.

Now, normally when these cultures clash, we're able to point to the
Debian netiquette guidelines, and move on.

In this particular instance, we've got a person from the second culture
who seems to have no idea that other cultures exist, or that a mailing
list might not adhere to their own expectations. This person is acting
belligerantly, and will not listen to gentle reminders.

The best course of action in this case is to drop it, but pride can make
people do the wrong things sometimes.

James H. H. Lampert

2024-05-14 18:00:02 UTC

Post by Greg Wooledge
We have a clash of two cultures here.

More than just *nix vs. M$.

In business communications by email, the norm is to quote the *entire*
thread, every time, without paring anything down, purely for the sake of
CYA. As such, top-posting is the only reasonable alternative, given that
recipients would otherwise have to scroll through hundreds, perhaps
thousands of lines of quoted material to find a bottom-posted reply, or
worse, *actually read* through all that quoted material to find an
inline-posted reply.

In list-server communications (and to a lesser extent, BBS posts), the
norm is to pare down quoted material to the barest minimum needed to
provide context (originally to save bandwidth and storage, both of which
are *still* finite resources), and to bottom-post or inline-post one's
replies, in order to give them a more natural flow. CYA doesn't factor
in at all.

--
JHHL

Nicolas George

2024-05-14 18:20:01 UTC

Post by Greg Wooledge
Usenet news. For people in this culture, there is a well-defined set
of "netiquette" rules -- plain text messages, inline quoting with "> "
citation characters, lines limited to ~72 characters, etc.

I slightly disagree with this wording: you make it sound like we follow
the rules just because they are there. Not so: we follow the rules
because they make sense, because they make conversations more fluid:

- Limiting to 72 characters was good because a lot of terminals were 80
columns, and it is still good because longer lines are hard to read
but mail software still is not smart enough to rewrap text by the mile
but not code.

- Trimmed interleaved quoting presents to the reader the exact
information they need in the order they need it to understand the
reply and what it is about.

In summary, the hackers culture expects the sender to spend a little
effort into making the mail easy to read for the recipient(s) while the
culture of the general population expects the sender to make as little
effort as possible and the recipient(s) to bear the burden that the
software in between cannot take, i.e. most of it.

And the “(s)” tells us which culture is more efficient and why.

Post by Greg Wooledge
The second culture are Windows users who grew up with Microsoft products
in their school or workplace. In this culture, top-posting is the norm,
and inline quoting is nigh impossible. Messages are often sent in either
HTML or markdown format.

Messages in Markdown in the Windows world? I have never seen it.

Post by Greg Wooledge
The best course of action in this case is to drop it

Indeed. But we can still discuss cultural issues relevant to
mailing-lists around it.

Regards,

--
Nicolas George

Karen Lewellen

2024-05-14 18:40:01 UTC

well, speaking personally, I can respect both sides.
I use a screen reader. Having to wade through loads of text, for a
conversational flow, especially when not edited is far from productive
for me personally.
it is much better to have a top post, for me personally, because I have no
issues reading below..if needful.
I can only imagine what it is like for folks on small screens, having to
translate from English etc.
Do I understand the conversation idea?
absolutely.
Do I also realize that if the thread is not edited the conversation is
less fluid and more a lake of mud?

Absolutely as well.
Karen

Post by Nicolas George

I slightly disagree with this wording: you make it sound like we follow
the rules just because they are there. Not so: we follow the rules
- Limiting to 72 characters was good because a lot of terminals were 80
columns, and it is still good because longer lines are hard to read
but mail software still is not smart enough to rewrap text by the mile
but not code.
- Trimmed interleaved quoting presents to the reader the exact
information they need in the order they need it to understand the
reply and what it is about.
In summary, the hackers culture expects the sender to spend a little
effort into making the mail easy to read for the recipient(s) while the
culture of the general population expects the sender to make as little
effort as possible and the recipient(s) to bear the burden that the
software in between cannot take, i.e. most of it.
And the â(s)â tells us which culture is more efficient and why.

Messages in Markdown in the Windows world? I have never seen it.

Post by Greg Wooledge
The best course of action in this case is to drop it

Indeed. But we can still discuss cultural issues relevant to
mailing-lists around it.
Regards,
--
Nicolas George

Greg Wooledge

2024-05-14 19:40:01 UTC

Post by Nicolas George
Messages in Markdown in the Windows world? I have never seen it.

I can't be sure where they're coming from exactly, but every once in
a while I see messages on debian-user, bug-bash or help-bash which
have extra asterisk characters scattered throughout them (usually
make the code samples break). The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

When reading the message with the idea that "this might be markdown
text" in mind, it's possible to guess, in most cases, which asterisks
should be removed to render the code samples or terminal session pastes
correct.

Max Nikulin

2024-05-15 02:20:01 UTC

Post by Nicolas George
Messages in Markdown in the Windows world? I have never seen it.

[...]

Post by Greg Wooledge
The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

*Bold*, /italics/, and _underlined_ markup is supported by various
mailers, e.g. Thunderbird and Gnus. Some render superscripts^1 and
subscripts_2 as well.

Backticks (`echo $PATH`) are more specific to markdown. However
sometimes I use them not expecting that the message will be rendered as
markdown. Just to avoid ambiguity where a piece of code starts and ends.

e***@gmx.us

2024-05-15 03:40:01 UTC

Post by Nicolas George
Messages in Markdown in the Windows world? I have never seen it.

[...]

Post by Greg Wooledge
The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

*Bold*, /italics/, and _underlined_ markup is supported by various
mailers, e.g. Thunderbird and Gnus. Some render superscripts^1 and
subscripts_2 as well.
Backticks (`echo $PATH`) are more specific to markdown. However
sometimes I use them not expecting that the message will be rendered as
markdown. Just to avoid ambiguity where a piece of code starts and ends.

If your mail path is sufficiently modern, you might be able to use Unicode
subscripts₁ and superscripts². But, they're kind of a pain to type for >1
character.

Darac Marjal

2024-05-15 15:00:01 UTC

Post by Nicolas George
Messages in Markdown in the Windows world? I have never seen it.

[...]

Post by Greg Wooledge
The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

*Bold*, /italics/, and _underlined_ markup is supported by various
mailers, e.g. Thunderbird and Gnus. Some render superscripts^1 and
subscripts_2 as well.
Backticks (`echo $PATH`) are more specific to markdown. However
sometimes I use them not expecting that the message will be rendered as
markdown. Just to avoid ambiguity where a piece of code starts and ends.

When this sort of subject comes up (as it does, every so often), I
wonder why `text/markdown` isn't offered as a mime type for sending
emails. If you're an MUA and you're going to parse text/plain for
markup, then why not offer text/markdown as the body of the message? I
know that there have been various attempts to bridge the gap between
"text/plain is too basic" and "text/html is too powerful" such as
text/enriched and text/rtf, but Markdown seems to be hitting a sweet
spot of being easy to write and being widely adopted elsewhere.

David

2024-05-15 18:50:01 UTC

Post by Darac Marjal

Post by Nicolas George
Messages in Markdown in the Windows world? I have never seen it.

[...]

Post by Greg Wooledge
The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

*Bold*, /italics/, and _underlined_ markup is supported by various
mailers, e.g. Thunderbird and Gnus. Some render superscripts^1 and
subscripts_2 as well.
Backticks (`echo $PATH`) are more specific to markdown. However
sometimes I use them not expecting that the message will be rendered as
markdown. Just to avoid ambiguity where a piece of code starts and ends.

Evolution delivers on a markdown option.\
Cheers!

Stefan Monnier

2024-05-16 13:30:01 UTC

When this sort of subject comes up (as it does, every so often), I wonder
why `text/markdown` isn't offered as a mime type for sending emails.

FWIW, last time I tried to send `text/(x-)markdown` messages,
I discovered that many "popular" MUAs do not display those at all (they
treat them as attachments, for example), contrary to what the RFCs say
they SHOULD do. 🙁

So, yes, I encourage you to send more of those, and if your recipients
don't like the result, try and get them to complain to their
MUA's authors (most of those MUAs are of course proprietary and are not
very ... responsive, but that's all we can do).

The stupidest case I bumped into is Github where replying by `plain/text`
email lets you add comments to an issue, but `text/markdown` replies are
simply sent to `/dev/null` even though Markdown is the standard format
they use in the web interface.

Stefan

t***@tuxteam.de

2024-05-16 13:50:01 UTC

On Thu, May 16, 2024 at 09:28:05AM -0400, Stefan Monnier wrote:

[...]

Post by Stefan Monnier
So, yes, I encourage you to send more of those, and if your recipients
don't like the result, try and get them to complain to their
MUA's authors (most of those MUAs are of course proprietary and are not
very ... responsive, but that's all we can do).

Actually I've been tempted to teach my mail reader to transform HTML
into some lightweight markup (yeah, you need a bit of heuristics for
that ;-) -- say Org, but why not its poor sister Markdown.

Post by Stefan Monnier
The stupidest case I bumped into is Github where replying by `plain/text`
email lets you add comments to an issue, but `text/markdown` replies are
simply sent to `/dev/null` even though Markdown is the standard format
they use in the web interface.

What'd you expect from Microsoft? -- Excelllllence!1!!

Cheers

--
t

Henning Follmann

2024-05-16 14:00:01 UTC

Post by t***@tuxteam.de
[...]

Actually I've been tempted to teach my mail reader to transform HTML
into some lightweight markup (yeah, you need a bit of heuristics for
that ;-) -- say Org, but why not its poor sister Markdown.

[...]
Please don't settle for markdown. I would love a org filter!
org-mode just handles tabular data admirably :)

-H

--
Henning Follmann | ***@itcfollmann.com

Stefan Monnier

2024-05-17 19:30:01 UTC

Post by t***@tuxteam.de
Actually I've been tempted to teach my mail reader to transform HTML
into some lightweight markup (yeah, you need a bit of heuristics for
that ;-) -- say Org, but why not its poor sister Markdown.

Please don't settle for markdown. I would love a org filter!
org-mode just handles tabular data admirably :)

Just beware that Org's code is generally written under the implicit
assumption that the Org document is trusted, so if you try to reuse
parts of Org's code to do the rendering be extra mindful of the
potential for security holes.
[ This applies to many other ELisp packages, of course; it's not
exclusive to Org. ]

Stefan

Henning Follmann

2024-05-17 21:20:01 UTC

Please don't settle for markdown. I would love a org filter!
org-mode just handles tabular data admirably :)

Very true,
but most content is unsafe like office (MS and open), PDF any other than
PDF-A. And HTML which can include JS.
org-mode can execute also other code than lisp, like python, JS, Lua

A filter though could be limited to only create safe org markup.

-H

--
Henning Follmann | ***@itcfollmann.com

Max Nikulin

2024-05-18 03:40:01 UTC

Please don't settle for markdown. I would love a org filter!
org-mode just handles tabular data admirably 🙂

Leaving aside that in bookworm emacs has not got an update fixing a
serious security issue, do you have an example of HTML to Org converter
that may generate unsafe markup?

Specifically to tables, I do not like that arbitrary code may be
executed in response to TAB or C-c C-c. However I am unsure if formulas
may appear in an Org file converted from HTML.

emacs-orgmode. Re: [BUG][Security] begin_src :var evaluated before the
prompt to confirm execution. Fri, 28 Oct 2022 11:11:18 +0700.

Post by Stefan Monnier
[ This applies to many other ELisp packages, of course; it's not
exclusive to Org. ]

Yesterday reading bug reports and emacs-devel threads related to

Post by Stefan Monnier
IMHO we should stop kow-towing to the information security people who
make a huge fuss over every single bug, especially bugs like this one
which only show up when you specifically try to trigger them.

t***@tuxteam.de

2024-05-18 05:50:01 UTC

Please don't settle for markdown. I would love a org filter!
org-mode just handles tabular data admirably :)

My tip of the hat towards Org was somewhat tongue-in-cheek. The
problem I actually see with Org (and with Markdown, to a lesser
extent) is that they are pretty ad-hocish and tinker friendly.

Which is a *big* plus on the one hand.

On the other, though, once you want to formalize the thing (a
prerequisite to be able to even start talking about security),
a myriad of dialects has evolved.

Then you either need a dictatorship (Github aka Microsoft, cf.
"github flavoured Markdown") or you have a long and painful
process (Org is trying, currently).

The upside of Org and Markdown is that you (currently, at least)
don't need a special reader to make sense of them.

But (that's the fourth or fifth hand?) if you follow the evolution
of HTML, back then (TM) you didn't need a special reader either.
Looking at the crud generated by e.g. "modern" Microsoft mailers,
though...

There's room for information technology sociologists here :)

Cheers

--
t

Max Nikulin

2024-05-16 17:00:01 UTC

I am not familiar with pandoc features enough to reason if it is safe
from security point of view.

for i in org markdown commonmark gfm ; do
printf '<strong>Bold %s</strong>' "$i" | pandoc -f html -t "$i" ;
done

*Bold org*
**Bold markdown**
**Bold commonmark**
**Bold gfm**

I believed that some text browser should render HTML well enough to make
messages readable in terminal.

Karl Vogel

2024-05-17 03:50:01 UTC

https://github.com/aaronsw/html2text/ might interest you. It converts
(relatively) sane HTML into Markdown.

I put html2text.py into $HOME/lib and use this to call it:

#!/bin/sh
#<html2mkd: convert reasonable HTML to Markdown
exec /usr/bin/env python $HOME/lib/html2text.py ${1+"$@"}
exit 1

--
Karl Vogel I don't speak for anyone but myself

Getting old has advantages. I can hide my own Easter Eggs, and young
ladies giggle when I give someone the finger.

Max Nikulin

2024-05-17 05:50:01 UTC

Post by Karl Vogel
https://github.com/aaronsw/html2text/ might interest you. It converts
(relatively) sane HTML into Markdown.
#!/bin/sh
#<html2mkd: convert reasonable HTML to Markdown
exit 1

I am puzzled by this wrapper. I expect that "$@" is enough here and
namely {1+"$@"} is redundant. Am I wrong?

Another question is what is advantage of a decade old Python-2 script
over the python3-html2text Debian package built (almost certainly) from
its successor:
<https://alir3z4.github.io/html2text>

Greg Wooledge

2024-05-17 11:20:01 UTC

Post by Karl Vogel
https://github.com/aaronsw/html2text/ might interest you. It converts
(relatively) sane HTML into Markdown.
#!/bin/sh
#<html2mkd: convert reasonable HTML to Markdown
exit 1

https://mywiki.wooledge.org/WrapperScript

Short version: "$@" is good enough if your /bin/sh isn't museum-era.
${1+"$@"} works around a bug in some very old shells.

Max Nikulin

2024-05-18 13:30:01 UTC

Post by Karl Vogel
https://github.com/aaronsw/html2text/ might interest you. It converts
(relatively) sane HTML into Markdown.
#!/bin/sh
#<html2mkd: convert reasonable HTML to Markdown
exit 1

[...]

Post by Greg Wooledge
https://mywiki.wooledge.org/WrapperScript

Thanks. I am unsure if a python2 script from 2011 is consistent with a
sh expanding "$@" to empty string, but the reason of the construct might
be just muscle memory or some guide.

The wiki article considers a symlink that was my original idea. It seems
"exit 1" can not ensure certain exit code even if exec fails (at least
with current versions of dash and bash). In addition I see no value of
/usr/bin/env in shell script. It is appropriate for the python script
shebang "#!/usr/bin/env python" (present since its initial commit).

P.S.
Portable shell section in autoconf manual mentions "${1+"$@"}" issues
with zsh (the script above requires /bin/sh explicitly):
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-_0022_0024_0040_0022

Greg Wooledge

2024-05-18 13:50:01 UTC

Post by Karl Vogel
https://github.com/aaronsw/html2text/ might interest you. It converts
(relatively) sane HTML into Markdown.
#!/bin/sh
#<html2mkd: convert reasonable HTML to Markdown
exit 1

[...]

Post by Greg Wooledge
https://mywiki.wooledge.org/WrapperScript

Thanks. I am unsure if a python2 script from 2011 is consistent with a sh
just muscle memory or some guide.

It has nothing to do with the program being exec-ed. The bug is in the
old implementations of /bin/sh. If you're on Debian, you don't need to
worry about it. There is *no* version of Debian which has a /bin/sh
which has this bug. Only legacy commercial Unix systems have it.

P.S.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-_0022_0024_0040_0022

*sigh* zsh....

Well, once again, there is no version of Debian that uses zsh as its
/bin/sh, so you should be OK here. But if you really want to use the
case $# workaround, I won't say you're wrong.

Curt

2024-05-16 15:10:02 UTC

When this sort of subject comes up (as it does, every so often), I wonder
why `text/markdown` isn't offered as a mime type for sending emails.

FWIW, last time I tried to send `text/(x-)markdown` messages,

Attribute quotes accurately.

https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guidelines.2C_and_Tips

Max Nikulin

2024-06-17 02:50:01 UTC

Post by Nicolas George
Messages in Markdown in the Windows world? I have never seen it.

[...]

Post by Greg Wooledge
The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

*Bold*, /italics/, and _underlined_ markup is supported by various
mailers, e.g. Thunderbird and Gnus.

I came across a document stating that in the case of Thunderbird the
source of inspiration was Jargon File

<http://catb.org/jargon/html/writing-style.html>
"Chapter 5. Hacker Writing Style"

See <https://www.bucksch.org/1/projects/mozilla/16507/>
"Ben Bucksch - Projects - Mozilla - TXT->HTML Conversion"

d***@howorth.org.uk

2024-05-14 19:40:01 UTC

Post by Greg Wooledge
In this particular instance, we've got a person from the second
culture who seems to have no idea that other cultures exist, or that
a mailing list might not adhere to their own expectations. This
person is acting belligerantly, and will not listen to gentle
reminders.

There's another point that this person doesn't seem to realize, which
is that he's the one asking for help, and so he should be making
efforts to adapt to the desires of those he wishes to help him, rather
than trying to insist they adapt to his ways :(

But there's a noticeably slower response to his posts now, so maybe
he'll learn by experience.

Cindy Sue Causey

2024-05-15 14:40:01 UTC

-----Original Message-----
From: Greg Wooledge <***@wooledge.org>
To: debian-***@lists.debian.org
Subject: Re: OT: Top Posting
Date: 05/14/24 13:41:17

Post by f***@protonmail.com
how many times has this top post crap been dug up
don't y'all have any thing better to do

It's never going to stop. We have a clash of two cultures here.

The first culture are Unix users who grew up with Internet email and
Usenet news. For people in this culture, there is a well-defined set
of "netiquette" rules -- plain text messages, inline quoting with "> "
citation characters, lines limited to ~72 characters, etc.

Too funny for words! Make that twice now that I've seen line length
mentioned here on Debian in over a decade++. I also referenced the
inline quoting method since my new chosen email software appears to be
failing with its default on that feature. Will try AGAIN to fix that as
soon as I hit "Send" here BECAUSE tech reply emails are difficult to
follow without those stacked ">" over ">>" pointers attached showing who
said what when.

And, yeah, netiquette, that's the word echoed across the Internet. I
totally forgot that in my own response. It's not users picking on each
other. It's a respectful "virtual handshake approved" set of standards
with the straightforward purpose of putting everyone on as close to the
same page as is humanly possible.

PS Afterthought is that email signatures are another of that widely
accepted netiquette set of standards. I consciously altered mine many
years ago after reading about that, most likely also here on Debian-
User. Might have been over on W3C, too, now that I think about it.
That's where I first heard of Linux circa 1999.

W3C's Linux reference was about installing HTML validators locally, and
the rest is terminal command line history. Thank you, Developers! What
you all do and that works so near flawlessly in nanoseconds still..
blows my mind to this.. second. Watching daily upgrades methodically
unfold as each package successfully coordinates its place in line with
the others is pure magic. :)

Cindy :)

--
Talking Rock, Pickens County, North Georgia
* runs with birdseed! *

Nicolas George

2024-05-15 15:00:01 UTC

Post by Cindy Sue Causey
PS Afterthought is that email signatures are another of that widely
accepted netiquette set of standards.

You can add the “Re: ” to that list.

It is the sequence of four octets 0x52, 0x65, 0x3a, 0x20, and nothing
else.

The MUAs who write “RE: ” are wrong.

The MUAs who write “Re : ” are wrong.

The MUAs who write “AW: ” are wrong.

The MUAs who put it in base64 are wrong.

It is not a string that is designed to be internationalized, we cannot
expect every MUA to know every stupid local or vanity variant of “Re: ”.

Regards,

--
Nicolas George

gene heskett

2024-05-15 18:10:02 UTC

Post by Nicolas George

Post by Cindy Sue Causey
PS Afterthought is that email signatures are another of that widely
accepted netiquette set of standards.

You can add the “Re: ” to that list.
It is the sequence of four octets 0x52, 0x65, 0x3a, 0x20, and nothing
else.
The MUAs who write “RE: ” are wrong.
The MUAs who write “Re : ” are wrong.
The MUAs who write “AW: ” are wrong.
The MUAs who put it in base64 are wrong.
It is not a string that is designed to be internationalized, we cannot
expect every MUA to know every stupid local or vanity variant of “Re: ”.

+ 5, Excellent point Nicolas
The same can be said for sig separators. One fellow here has it as part
of his sig but his definition in his sig is incomplete.
Its actually an lf,dash,dash,space.lf ignoring the comma's I used
here..Some email agents won't use it as a sig separator w/o the full
lf's as wrapper. cr's are not valid subs for the lf's..

Post by Nicolas George
Regards,

Take care & stay well Nicolas.

Cheers, Gene Heskett, CET.

Andrew M.A. Cater

2024-05-14 18:30:02 UTC

Post by f***@protonmail.com
how many times has this top post crap been dug up
don't y'all have any thing better to do
i know
how about some real debian issues

Hi,

Have a quick look at the Debian-user FAQ posted each month and the
Debian Code of Conduct.

Both of those are real Debian issues - they're part of the way that
this mailing list operates so that people can read and understand
long threads. They also allow us to maintain smaller archives
that nonetheless retain the important information.

May I suggest that you look back at about 30 years worth of the
history here?

All the very best, as ever,

Andy
(***@debian.org)

Andy Smith

2024-05-14 21:20:02 UTC

Hello,

Post by f***@protonmail.com
don't y'all have any thing better to do

You must be new here.

Get used to reading with a "mark thread read" key in your MUA of
choice, is my best advice.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

f***@protonmail.com

2024-05-14 21:40:01 UTC

Post by Andy Smith
Hello,

Post by f***@protonmail.com
don't y'all have any thing better to do

You must be new here.

sorta
i've only been using versions of linux since the early 90's :)
downloaded it from an archie server on to 2 floppies

Post by Andy Smith
Get used to reading with a "mark thread read" key in your MUA of
choice, is my best advice.

i've got to admit to being weak
reading the brilliant and riveting prose is addictive
and entertainment is in short supply around here
especially after the chickens go to bed

Post by Andy Smith
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting

Cindy Sue Causey

2024-05-15 13:50:02 UTC

-----Original Message-----
From: gene heskett <***@shentel.net>
To: debian-***@lists.debian.org
Subject: Re: OT: Top Posting
Date: 05/14/24 10:54:50

On 5/14/24 10:09, Richard wrote:
Just because something isn't an official ISO standard doesn't mean
it's
not standard behavior. And how it relates to this mailing list? It's
called a setting.

No its not, its your refusal to use the down arrow in your reply editor
to put your reply after the question. It really is that simple. If your
choice of email agents cannot do that, its time to switch to an agent
that can. There are dozens of them.

DISCLAIMER: I just realized above portion might not quote properly. My
apologies in advance if it does not. That's one glitch I haven't located
a fix for, yet.

The rest of the email: I think Evolution has finally fixed my own latest
issues with tech reply emails just since Gmail forced all users onto its
more dynamic release. My biggest issue is, hopefully "was," line length.
This email is only my second reply sent in maybe 2 months so am about to
find out how things are progressing.

Accidentally just this second was reminded there's a setting for
avoiding top posting by lunging to bottom of reply emails. That setting
is found by going through the now classic 3-line settings "hamburger"
then:

Edit > Preferences > Composer Preferences > General (tab)

There's a simple toggle on/off checkbox that says, "Start typing at the
bottom." The setting for word wrapping is just a few lines above that.

Regarding line length (word wrapping), that's an even less spoken
"standard" that has merit at its base. I think I've seen it mentioned
maybe one time in more than a decade++ on Debian. That "standard" is
about usability.. readability.. aka conscious consideration for fellow
list members.

Best as I was able to discern from the Net [0], 72 characters is the
magic number for line length because 4 extra characters are added to
both ends when e.g. git processes submissions. Makes good common sense
to me.

PS I thought it was 80. Guess it was about those extra 8 characters.
Or.. Maybe whoever I saw write that over ten years ago almost understood
that "handshake standard" but not quite. That's one scary part of
trusting strangers on the WWW. :)

Again back to the concept of tech listserv standards, the source I'm
referencing after randomly finding it via search this morning says, "The
50/72 Rule is a set of standards that are pretty well agreed upon in the
industry to standardize the format of commit messages."

"Pretty well agreed upon..." That's implying that unspoken list
standards are really not users "picking on each other." Listserv
standards is a concept that has evolved over decades for rational
reasons as Developer and User communications evolved.

Am not embarrassed to say Evolution has kicked my backside k/t its
learning curve versus a user's level of cognitive ability. This
experience ended up touching on "frightening" a couple times, e.g. I
sent 2,000 online emails to (online) trash when that was not intended.
It's easy to mess up badly while moving emails around between desktop
folders because that activity directly affects the linked online email
provider if a user approves those access permissions.

For what it's worth as a huge selling point for me, I have a massive
online email account. There are hundreds of thousands of emails from the
last 20 years. Evolution said whatever, bring it on.

Evolution appears to do some form of maybe symlinking instead of
downloading so everything is available almost immediately seconds after
the first time Evolution is ever fired up. Other email software I've
used only seems to work by downloading. That difference is huge for
anyone using a data download limiting Internet provider. NOTE: Evolution
appears to possibly offer related tweaking if one prefers working
offline.

In the other email software cases I attempted, the software could only
reach back a limited time span into history before I a-sume Gmail cut
off access to touching older emails. If there's a work-around for that,
I never found it. I simply (and immediately) purged the email software,
instead.

With Evolution, I'm instantly looking at emails I haven't seen in ~20
years. I was having a horrible time accessing those same emails in Gmail
itself online. Talk about mind blowing nostalgia overload...

Cindy :)

[0]
https://dev.to/noelworden/improving-your-commit-message-with-the-50-72-rule-3g79

--
Talking Rock, Pickens County, North Georgia
* runs with birdseed! *

Nicolas George

2024-05-15 14:10:01 UTC

Post by Cindy Sue Causey
Best as I was able to discern from the Net [0], 72 characters is the
magic number for line length because 4 extra characters are added to
both ends when e.g. git processes submissions. Makes good common sense
to me.

Git is an order of magnitude younger than the limit at 72 characters.

Post by Cindy Sue Causey
PS I thought it was 80. Guess it was about those extra 8 characters.

It is 80 but you anticipate that people will be adding “> ” in front of
your lines.

Post by Cindy Sue Causey
"Pretty well agreed upon..." That's implying that unspoken list
standards are really not users "picking on each other." Listserv
standards is a concept that has evolved over decades for rational
reasons as Developer and User communications evolved.

Indeed.

Post by Cindy Sue Causey
It's easy to mess up badly while moving emails around

As a general rule, GUIs suck at anything but trivial tasks.

Post by Cindy Sue Causey
Evolution appears to do some form of maybe symlinking instead of
downloading so everything is available almost immediately seconds after
the first time Evolution is ever fired up.

The IMAP protocol is designed to let us manipulate mails directly on the
server without downloading the bulk of them. A lot of GUI MUA are still
designed around the old paradigm where mails are downloaded, and turned
it into some kind of cache: it rarely works well.

Manipulate mails directly on the server. Have a backup. If your server
is often down and accessing the mails is urgent, have a local *copy* of
it.

Post by Cindy Sue Causey
reach back a limited time span into history before I a-sume Gmail cut
off access to touching older emails.

If you want mail that works well, start by avoiding services meant for
the lowest common denominator of the general public.

Regards,

--
Nicolas George

gene heskett

2024-05-15 14:50:01 UTC

Post by Nicolas George

Git is an order of magnitude younger than the limit at 72 characters.

Post by Cindy Sue Causey
PS I thought it was 80. Guess it was about those extra 8 characters.

It is 80 but you anticipate that people will be adding “> ” in front of
your lines.

Indeed.

Post by Cindy Sue Causey
It's easy to mess up badly while moving emails around

As a general rule, GUIs suck at anything but trivial tasks.

The IMAP protocol is designed to let us manipulate mails directly on the
server without downloading the bulk of them. A lot of GUI MUA are still
designed around the old paradigm where mails are downloaded, and turned
it into some kind of cache: it rarely works well.
Manipulate mails directly on the server. Have a backup. If your server
is often down and accessing the mails is urgent, have a local *copy* of
it.

Post by Cindy Sue Causey
reach back a limited time span into history before I a-sume Gmail cut
off access to touching older emails.

If you want mail that works well, start by avoiding services meant for
the lowest common denominator of the general public.
Regards,

I'll add that googles gmail, written by former outlook developers is the
biggest pita to ever hit the net. They break every rfc that can.

Cheers, Gene Heskett, CET.

Greg Wooledge

2024-05-15 14:50:01 UTC

For many decades, there was an industry standard that lines of text
should be up to 80 characters wide. Punch cards were 80 characters wide,
for example. I don't know whether punch cards were the *first* place
it appeared, but they're the first I'm aware of.

A lot of the printers from the last century allowed 80 characters
per line on standard US 8.5x11 inch paper. I'm not sure if teletypes
used 80-column paper, or 133-column paper (green bar), or a mixture.

Later, we got terminals. A typical ASCII terminal (a physical one, like
a DEC VT-100) is 80x24 characters, or sometimes 80x25. The 80-character
line standard continued.

When hardware evolved and most of us started using X11 or similar GUI
interfaces, terminal emulators became the norm. xterm and other software
terminal emulators use an 80x24 window as the default, for compatibility
with physical terminals.

When writing code in most programming languages, there are style guides
that still suggest sticking to 80-character lines whenever possible.
It avoids line wrapping when being read in an 80-character terminal,
and besides that, really long lines of code are harder to read than
shorter lines.

When it comes to email or Usenet, though, the 72-character suggestion
is meant to allow a bit of room for quoting markup. If I write a
79-character line of text, and then you reply to it with "> " in front,
the resulting 81-character line of text either gets wrapped or truncated.
Limiting yourself to 72-character lines allows a few levels of quoting
before the text becomes unreadable.

This is why the 72-character limit is just a suggestion, not a hard
requirement. If you write lines that are 74 characters wide, probably
nobody's going to care. The goal is simply to make it easy to carry
on a conversation.

Henning Follmann

2024-05-15 16:10:02 UTC

Since my request started this offtopic subthread I hope I can put it to
rest.
Yes I requested to not toppost. I asked politely, and I added pertinent
response on topic. I do not claim to be right or wrong about this. I prefer
interleaved style for reason. Everyone on this list heard all arguments pro
and con in previous discussions, and there is no need to repeat them. It is
a matter of personal choice though I have to admit I feel a bit emboldened by
the posting guidelines. And in my experience a polite question goes a long
way with most civilized people. You can ignore my request, well you even
ask me to toppost. I will ignore it.
There is no need for a lecture, you have no claim to right or wrong either.
Claiming a de facto industry standard (I avoided the literally sidebar
here) on majority is a questionable argument. Large numbers do not make
right. There are many examples where the majority is wrong. Well I go along
with majority practice knowing they are wrong, just to make life easier.
I try not to yell at people though for choosing differently. And it is
questionable to get you anywhere anytime fast. And I do not like that Gene
was called an "epitome of humanity" in a cynical way and I earned a
hypocrite long after I copped out of that discussion.

Please let this rest.

-H

--
Henning Follmann | ***@itcfollmann.com

James H. H. Lampert

2024-05-15 16:50:01 UTC

On 5/15/24 6:46 AM, Cindy Sue Causey wrote:
. . .

Post by gene heskett
No its not, its your refusal to use the down arrow in your reply editor
to put your reply after the question. It really is that simple. If your
choice of email agents cannot do that, its time to switch to an agent
that can. There are dozens of them.

. . .

Actually, it isn't necessarily the user's fault. Thanks to the "business
standard," (and think about the initials) of top-posting over the
complete, unpared quote of the entire thread, there are an awful lot of
email readers (and especially webmail interfaces) that make it difficult
to follow any other convention, and a few that make it damn-near impossible.

Just as there are an awful lot that make it difficult or impossible to
send a plain-text email.

Incidentally, regarding the Hollerith card origins of the 80-column
standard, the very first Hollerith cards, from the 1890 U.S. Census, had
24 columns and 12 rows of round holes, and were punched with a
pantograph punch. In 1928, IBM introduced rectangular holes, in an
80-column, 10-row format, later expanded to 12 rows.

--
JHHL

t***@tuxteam.de

2024-05-14 15:30:01 UTC

Post by Richard
Just because something isn't an official ISO standard doesn't mean it's not
standard behavior. And how it relates to this mailing list? It's called a
setting.

Most people prefer inline quoting around here (I know I do). That's
because for big mailing lists, with long threads, it works much, much
better.

That said, we usually are tolerant of top posts. What gets me
is the hostility of your reaction. You aren't going to convince
anyone. Even not with "industry standards" [1]

As far as your main concern goes... I lost interest.

Cheers

[1] Q: How many Microsoft technicians does it take to change a
light bulb?
A: None, they just redefine Darkness (TM) as the new industry
standard.
https://www.linux.com/news/how-many-microsoft-technicians-does-it-take-change-light-bulb/

--
t

Henning Follmann

2024-05-14 14:00:01 UTC

Post by Richard
"Top posting" (writing the answer above the text that's being replied to)
is literally industry standard behavior.

Whatever.
It is not standard behavior in mailing lists.
https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guidelines.2C_and_Tips

But I just asked you to not to. You can ignore that, as you do.

Good luck with your issues.

Post by Richard
Also, I don't think you've really cleared out any confusion. Now, how
exactly can dovecot log to /var/log/dovecot/ without (postfix) throwing
errors? Because it clearly is for 2 out of 3 files as visible from the file
sizes in my original post. Only the debug file is empty, but maybe nothing
relevant enough has been found yet. There are entries from master,
imap, imap-login, managesieve-login, anvil and various other processes in
info and error. But the error messages from postfix still appear, also
seemingly at least vastly slowing down emails being delivered to the users,
if not bringing that to a complete halt. Only after commenting out these
locations in 10-logging.conf the mails show up for the users.

-H

--
Henning Follmann | ***@itcfollmann.com

Richard

2024-05-14 18:50:01 UTC

Says the one refusing to stay on topic. What a sad hypocrite.

Post by Richard
"Top posting" (writing the answer above the text that's being replied to)
is literally industry standard behavior.

Whatever.
It is not standard behavior in mailing lists.
https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guidelines.2C_and_Tips
But I just asked you to not to. You can ignore that, as you do.
Good luck with your issues.

file

Post by Richard
sizes in my original post. Only the debug file is empty, but maybe

nothing

Post by Richard
relevant enough has been found yet. There are entries from master,
imap, imap-login, managesieve-login, anvil and various other processes in
info and error. But the error messages from postfix still appear, also
seemingly at least vastly slowing down emails being delivered to the

users,

Post by Richard
if not bringing that to a complete halt. Only after commenting out these
locations in 10-logging.conf the mails show up for the users.

-H
--

Alain D D Williams

2024-05-14 15:40:01 UTC

Post by Richard
"Top posting" (writing the answer above the text that's being replied
to) is literally industry standard behavior.

Many do top post, but many do not.

Places where it is often frowned on are technical mail lists such as this one.
This is because only quoting to the parts of the mail that you reply to and
putting you comment underneath can greatly help understanding.

Read the Netiquette Guidelines (1995):

https://www.ietf.org/rfc/rfc1855.txt

Other discussions here:

https://idallen.com/topposting.html

https://www.caliburn.nl/topposting.html

PS: check the dictionary definition of "literally".

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

Nicolas George

2024-05-14 15:50:01 UTC

Post by Alain D D Williams
PS: check the dictionary definition of "literally".

I think you should have checked first that it makes the point you want
to make and not the opposite:

2. (degree, figuratively, proscribed, contranym) Used non-literally as
an intensifier for figurative statements: virtually, so to speak
(often considered incorrect; see usage notes)
3. (colloquial) Used to intensify or dramatize non-figurative
statements.
4. (colloquial) Used as a generic downtoner: just, merely.
<https://en.wiktionary.org/wiki/literally>

2. in effect : virtually—used in an exaggerated way to emphasize a
statement or description that is not literally true or possible
<https://www.merriam-webster.com/dictionary/literally>

* used to emphasize what you are saying:
* simply or just:
<https://dictionary.cambridge.org/dictionary/english/literally>

Regards,

--
Nicolas George

jeremy ardley

2024-05-14 12:00:01 UTC

Post by jeremy ardley
Postfix is chrooted (usuallly) to /var/spool/postfix

If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.
I could imagine the Postfix SMTP sending/receiving and queue processing
programs being chrooted, but the LDA probably isn't. Or at least not
chrooted to /var/spool/postfix.

From what I can find out, the postfix local delivery agent is not
chroot and it communicates with the main postfix processes via shared
directories and pipes.

To debug the problem I suggest checking the chroot and non chroot
processes and eliminate those that are not relevant to the seen error
messages

Richard

2024-05-14 17:30:01 UTC

How exactly do I do that?

Am Di., 14. Mai 2024 um 18:40 Uhr schrieb jeremy ardley <

Post by jeremy ardley
From what I can find out, the postfix local delivery agent is not
chroot and it communicates with the main postfix processes via shared
directories and pipes.
To debug the problem I suggest checking the chroot and non chroot
processes and eliminate those that are not relevant to the seen error
messages

t***@tuxteam.de

2024-05-14 11:50:02 UTC

On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:

[...]

Post by jeremy ardley
Postfix is chrooted (usuallly) to /var/spool/postfix
If postfix complains about /var/log/dovecot it's actually complaining about
/var/spool/postfix/var/log/dovecot

I'm sceptical about this -- the error would have been ENOENT, not EPERM
(because an intervening directory would be missing).

But of course, I might be wrong.

Cheers

--
t

t***@tuxteam.de

2024-05-14 04:40:01 UTC

I think this Dovecot's LDA (the local delivery agent) [1], which is
invoked by the MTA (Postfix) and is, therefore, most probably running
as postfix.

[...]

net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't
open log file /var/log/dovecot/error.log: Permission denied )

This message actually is an indicator against the chroot theory posed
elsewhere in this thread (in a chroot, you would get "no such file or
directory", I guess).

Post by Richard
-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log
-rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log
-rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log

Try to set the log file's group to mail (or whatever group Postfix is
running as) and make them group writable.

Cheers

--
t

Richard

2024-05-14 11:40:01 UTC

My guess is that postfix runs as postfix. At least processes like local,
smtpd, bounce etc run as that user. But beyond that I have no idea how to
find that out. At least there's nothing in the postfix.service or
***@.service
about that. So I've changed the files to dovecot:postfix 664, but same
error.

Post by Richard
Maybe someone here knows how the ownership of these files for Dovecot

needs

Post by Richard
to be in order to work, as various distributions of Dovecot packages seem
I'd like Dovecot not to log into syslog, but to dedicated files.

Therefore

Post by Richard
I've created the directory /var/log/dovecot and told dovecot in
10-logging.conf to log info, debug and error messages to separate files.

I think this Dovecot's LDA (the local delivery agent) [1], which is
invoked by the MTA (Postfix) and is, therefore, most probably running
as postfix.
[...]

net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied

Can't

open log file /var/log/dovecot/error.log: Permission denied )

This message actually is an indicator against the chroot theory posed
elsewhere in this thread (in a chroot, you would get "no such file or
directory", I guess).

Post by Richard
-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log
-rw-r--r-- 1 dovecot dovecot 880 13. Mai 21:21 error.log
-rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log

Try to set the log file's group to mail (or whatever group Postfix is
running as) and make them group writable.
Cheers
--
t

t***@tuxteam.de

2024-05-14 11:50:01 UTC

Post by Richard
My guess is that postfix runs as postfix.

That would be my guess too (or perhaps as some special "Debian-+postfix".

Post by Richard
At least processes like local,
smtpd, bounce etc run as that user. But beyond that I have no idea how to
find that out. At least there's nothing in the postfix.service or
about that. So I've changed the files to dovecot:postfix 664, but same
error.

You might try

ps -eo pid,user,group,comm | grep postfix

or similar. Or have a look at Posrfix's log file ownerships.

You might try making the log files in question world writable just
to see whether the problem disappears or this approach is a blind
alley (don't forget to revert that: leaving them world-writable
seems like asking for trouble).

Cheers

--
t

Florent Rougon

2024-05-14 12:10:02 UTC

Post by t***@tuxteam.de
You might try
ps -eo pid,user,group,comm | grep postfix
or similar.

Yep, and beware that the original message mentions a postfix program
named 'local' (/usr/lib/postfix/sbin/local).

Post by t***@tuxteam.de
May 13 20:55:37 mail postfix/local[2824184]: (...)

Regards

--
Florent

t***@tuxteam.de

2024-05-14 12:20:01 UTC

On Tue, May 14, 2024 at 02:11:53PM +0200, Richard wrote:

[...]

Setting the permissions in /var/log/dovecot to 666 actually didn't
solve the problem [...]

This seems to prove (or, at least, strongly suggest) that I was barking
up the wrong tree. I've currently run out of trees and at $DAYJOB, so
tight on resources. Good luck :)

Cheers

--
t

jeremy ardley

2024-05-14 22:50:01 UTC

Post by t***@tuxteam.de
[...]

Setting the permissions in /var/log/dovecot to 666 actually didn't
solve the problem [...]

This seems to prove (or, at least, strongly suggest) that I was barking
up the wrong tree. I've currently run out of trees and at $DAYJOB, so
tight on resources. Good luck :)

Clarifying my understanding of the issues I have discovered that postfix runs a non chroot service 'local' that has the initial responsibility to deliver mail locally.

local runs as root and has the ability to deliver mail to local files

local also has the ability to delegate the delivery to dovecot and other agents. This can be configured in postfix main.conf as

virtual_transport = lmtp:unix:private/dovecot-lmtp or mailbox_transport = lmtp:unix:private/dovecot-lmtp

From the postfix howto guide

mailbox_transport_maps (default: empty)

Optional lookup tables with per-recipient message delivery transports to use for local(8) mailbox delivery, whether or not the recipients are found in the UNIX passwd database.

The precedence of local(8) delivery features from high to low is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, mailbox_command_maps,
mailbox_command, home_mailbox, mail_spool_directory, fallback_transport_maps, fallback_transport and luser_relay.

https://www.postfix.org/local.8.html

https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/

Richard

2024-05-15 10:30:01 UTC

Interesting. That's not even configured in our main.cfg. We have these
concerning dovecot:
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER

But that's still not that helpful for the main issue. Why on earth is
postfix throwing issues about the log files, even when they are
world-readable and -writable? It's not that dovecot doesn't log to them,
but it's also not the case that it's an error message that can just be
ignored, as it brings mail delivery to a halt.

Am Mi., 15. Mai 2024 um 05:00 Uhr schrieb jeremy ardley <

Post by jeremy ardley
This can be configured in postfix main.conf as
virtual_transport = lmtp:unix:private/dovecot-lmtp or mailbox_transport
= lmtp:unix:private/dovecot-lmtp
From the postfix howto guide
mailbox_transport_maps (default: empty)
Optional lookup tables with per-recipient message delivery transports
to use for local(8) mailbox delivery, whether or not the recipients are
found in the UNIX passwd database.
aliases, .forward files, mailbox_transport_maps, mailbox_transport,
mailbox_command_maps,
mailbox_command, home_mailbox, mail_spool_directory,
fallback_transport_maps, fallback_transport and luser_relay.
https://www.postfix.org/local.8.html
https://doc.dovecot.org/configuration_manual/howto/postfix_dovecot_lmtp/

jeremy ardley

2024-05-15 10:40:01 UTC

Post by Richard
Interesting. That's not even configured in our main.cfg. We have these
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER

The sasl line is not relevant

The mailbox_command is unusual. It means whatever process actually
execute the mailbox_command runs as (some) postfix user to run the
deliver application. This may well cause permission issues.

The usual case is dovecot listens for commands on a unix socket or maybe
an IP socket. In any case it has an entirely separate user ID from postfix.

You may want to look at using the mailbox_transport option instead of
the mailbox_command option

mailbox_transport = lmtp:unix:private/dovecot-lmtp

Richard

2024-05-15 11:00:02 UTC

mailbox_transport isn't defined anywhere.

Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley <

Post by jeremy ardley

Post by Richard
Interesting. That's not even configured in our main.cfg. We have these
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER

The sasl line is not relevant
The mailbox_command is unusual. It means whatever process actually
execute the mailbox_command runs as (some) postfix user to run the
deliver application. This may well cause permission issues.
The usual case is dovecot listens for commands on a unix socket or maybe
an IP socket. In any case it has an entirely separate user ID from postfix.
You may want to look at using the mailbox_transport option instead of
the mailbox_command option
mailbox_transport = lmtp:unix:private/dovecot-lmtp

jeremy ardley

2024-05-15 11:00:02 UTC

Post by Richard
mailbox_transport isn't defined anywhere.
Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley

Post by Richard
Interesting. That's not even configured in our main.cfg. We have

these

Post by Richard
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER

The sasl line is not relevant
The mailbox_command is unusual. It means whatever process actually
execute the mailbox_command runs as (some) postfix user to run the
deliver application. This may well cause permission issues.
The usual case is dovecot listens for commands on a unix socket or maybe
an IP socket. In any case it has an entirely separate user ID from postfix.
You may want to look at using the mailbox_transport option instead of
the mailbox_command option
mailbox_transport = lmtp:unix:private/dovecot-lmtp

Then you may want to look at the manuals and find out how to add a
mailbox_transport entry and comment out the mailbox_command entry.

There are many other options of course, but mailbox_transport is a very
common configuration and usually avoids most permission issues.

Henning Follmann

2024-05-15 12:00:01 UTC

On Wed, May 15, 2024 at 12:23:35PM +0200, Richard wrote:
[...]

Post by Richard
But that's still not that helpful for the main issue. Why on earth is
postfix throwing issues about the log files, even when they are
world-readable and -writable? It's not that dovecot doesn't log to them,
but it's also not the case that it's an error message that can just be
ignored, as it brings mail delivery to a halt.

Maybe because you write directly to the logfile. One process trying to write
t it while a different already holds a lock to it.

-H

--
Henning Follmann | ***@itcfollmann.com

Richard

2024-05-16 11:10:01 UTC

But why is postfix even holding a lock on it? And how do I prevent that? I
never asked it to.
At least, I don't think there should be a different process holding a lock
on it.

Am Mi., 15. Mai 2024 um 18:45 Uhr schrieb Henning Follmann <

Post by Henning Follmann
[...]

Maybe because you write directly to the logfile. One process trying to write
t it while a different already holds a lock to it.
-H
--

Henning Follmann

2024-05-16 12:40:01 UTC

Post by Richard
But why is postfix even holding a lock on it? And how do I prevent that? I
never asked it to.
At least, I don't think there should be a different process holding a lock
on it.

I told you where to look, which is more than you deserve after how you
behave.
Configure the literal industry standard syslog or journald to use a
facility to your liking and the problem should resolve itself.

-H

--
Henning Follmann | ***@itcfollmann.com

Richard

2024-05-17 08:20:01 UTC

So now that you don't know any further, you just start lying? Now that's
rich.

Post by Henning Follmann
I told you where to look, which is more than you deserve after how you

behave.

You didn't though.

Post by Henning Follmann
Configure the literal industry standard syslog or journald to use a facility

to your liking and the problem should resolve itself.
The point is, Dovecot has an option to write certain types of logs to
different files. While it's doing that great, postfix is upset about that
capability. It shouldn't even try to access these files. So the issue is
not being able to log to files, that's already solved, but postfix running
crazy when using a very simple setting.

Am Do., 16. Mai 2024 um 18:55 Uhr schrieb Henning Follmann <

Post by Richard
But why is postfix even holding a lock on it? And how do I prevent that?

Post by Richard
never asked it to.
At least, I don't think there should be a different process holding a

lock

Post by Richard
on it.

Henning Follmann

2024-05-17 12:30:01 UTC

Post by Richard
So now that you don't know any further, you just start lying? Now that's
rich.

Post by Henning Follmann
I told you where to look, which is more than you deserve after how you

behave.
You didn't though.

Don't call me a liar, you are just too dumb to understand.

Post by Henning Follmann
Configure the literal industry standard syslog or journald to use a facility

No the point is, you are not setting a file path, you are configure dovecot
to directly write to these files.
And dovecot is not just one process, there are multiple running as
different users all trying t write into one file. Race conditions are
to be expected. Because these options exist does not mean it is a good
decision to use them.
And because you clearly don't understand what you are doing, do as being told.
Configure syslog or rsyslog to use that file path.

-H

--
Henning Follmann | ***@itcfollmann.com

Greg Wooledge

2024-05-17 12:30:01 UTC

Post by Henning Follmann
No the point is, you are not setting a file path, you are configure dovecot
to directly write to these files.
And dovecot is not just one process, there are multiple running as
different users all trying t write into one file. Race conditions are
to be expected. Because these options exist does not mean it is a good
decision to use them.

This is speculation. When writing to log files, one normally opens the
file in append mode. Multiple processes opening a single log file in
append mode, and using atomic write() calls, will not have any locking
or concurrency issues. It'll just work.

Now, the question is whether Dovecot and Postfix both work this way. I
don't use those two programs, so I don't know the answer to that.

It has become apparent that nobody on this mailing list has the intimate
technical knowledge of Dovecot and/or Postfix required to assist the OP
with setting up this nonstandard logging configuration. I would suggest
that the OP should try on a Dovecot or Postfix support list instead.

Richard

2024-05-18 13:20:01 UTC

Post by Henning Follmann
Don't call me a liar, you are just too dumb to understand.

It's sad to see that you need to make it this blatantly obvious that even I
clearly understand more than you do. And you're the one trying to scold me
about sticking to the mailing list rules when you so obviously don't care
for them yourself.

No the point is, you are not setting a file path, you are configure dovecot

Post by Henning Follmann
to directly write to these files.

I'm configuring dovecot the way it wants to be configured if you want to
deviate from default settings. What doesn't want to get to your brain is
that dovecot isn't the issue. Without postfix interfering everything would
be fine. It's postfix causing issues, not dovecot. Very simple logic would
have told you that, but you are way too focused on hatred and on knowing
everything better without actually doing so. I'm sorry but if you don't
have any clue of what you are talking about, just don't reply. Also you may
want to refrain from further replies - or attacks in your case - before you
write something you can't take back.

Richard

2024-05-14 12:20:01 UTC

Post by t***@tuxteam.de
ps -eo pid,user,group,comm | grep postfix
2886706 postfix postfix pickup
2886707 postfix postfix qmgr
2886764 postfix postfix tlsmgr

Also as far as I know, postfix logs to syslog too. At least there is no
dedicated file or folder for it in /var/log.

Setting the permissions in /var/log/dovecot to 666 actually didn't
solve the problem, which just opens a whole other bunch of questions. So in
case that for some odd reason AppArmor logs aren't logged to syslog (and
also it doesn't have a dedicated file), these are the rules for dovecot and
postfix I could find:
postfix has an apparmor (in abstractions) file that doesn't say anything
about /var/log. It only has these rules for things in /var:

/var/spool/postfix/etc/* r,
/var/spool/postfix/lib/lib*.so* mr,
/var/spool/postfix/lib/@{multiarch}/lib*.so* mr,

Dovecot has two files. In tunables you can find this:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories
# where dovecot is allowed to store and read mails
#
# The default value is quite broad to avoid breaking existing setups.
# Please change @{DOVECOT_MAILSTORE} to (only) contain the directory
# you use, and remove everything else.

@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/
/var/vmail/ /var/mail/ /var/spool/mail

Which doesn't seem to be relevant for this. No idea how dovecot can put the
mail into /maildirs/username, but since that's working I'm not complaining.
The file in abstractions only contains this:
# used with dovecot/*

abi <abi/3.0>,

capability setgid,

deny capability block_suspend,

# dovecot's master can send us signals
signal receive peer=dovecot,

owner @{run}/dovecot/config rw,

# Include additions to the abstraction
include if exists <abstractions/dovecot-common.d>

Post by t***@tuxteam.de

Post by Richard
My guess is that postfix runs as postfix.

That would be my guess too (or perhaps as some special "Debian-+postfix".

You might try
ps -eo pid,user,group,comm | grep postfix
or similar. Or have a look at Posrfix's log file ownerships.
You might try making the log files in question world writable just
to see whether the problem disappears or this approach is a blind
alley (don't forget to revert that: leaving them world-writable
seems like asking for trouble).
Cheers
--
t

Richard

2024-05-19 15:00:01 UTC

So, I've just written to the Dovecot mailing list, the reality why Dovecot
is complaining is so much worse than anything I could have imagined. While
everything indicates Dovecot is able to write to the log files, it seems
Dovecot expects execution permissions on the directory it writes the logs
to. Because "Standard POSIX permissions for a non-root process to enter a
directory." How on earth is that even a thing? Beyond binaries there
shouldn't really be any excuse for that many things to have execution
permissions on anything.

Greg Wooledge

2024-05-19 15:10:01 UTC

Post by Richard
Dovecot expects execution permissions on the directory it writes the logs
to. Because "Standard POSIX permissions for a non-root process to enter a
directory." How on earth is that even a thing?

That's how Unix permissions have always worked. In order to access
a file, you need +x permissions on *all* of the directories leading
up to that file, and then appropriate permissions on the file itself.

If you have read permission on a directory but *not* execute permissions,
then the only thing you can do is read the contents of that directory --
the filenames and their inode numbers. You cannot stat() the files,
so you can't see who owns them or even what kind of files they are.
Just their names.

If you have execute permission but *not* read permission on a directory,
then you can access the files within the directory, but only if you
already know their names. You can't read the directory to get their
names.

Likewise, write permission on a directory allows you to rename or unlink
files contained within that directory (because the names are not a
property of the files -- they are part of the *directory*). You don't
need write permission on a file to unlink it. Only on the directory.

Stefan Monnier

2024-05-19 15:20:01 UTC

Post by Greg Wooledge
If you have read permission on a directory but *not* execute permissions,
then the only thing you can do is read the contents of that directory --
the filenames and their inode numbers. You cannot stat() the files,
so you can't see who owns them or even what kind of files they are.
Just their names.

Never found a situation where this as useful.

Post by Greg Wooledge
If you have execute permission but *not* read permission on a directory,
then you can access the files within the directory, but only if you
already know their names. You can't read the directory to get their
names.

This OTOH is very handy, making the filename into a kind of "passwd" to
access the file's content.

Stefan

Michael Kjörling

2024-05-19 16:30:01 UTC

Never found a situation where this as useful.

Put the user that a HTTP server runs in into each user's group, and
set g=x on each user's home directory plus ~/public_html. (Your choice
whether you want g=rx or g=x on the latter.) The web server process is
now able to access web content from within the user's home directory
without needing to run anything as root (possibly after dropping
privileges after binding to ports 80 and 443), and all this without
giving anyone else any access into other users' home directories.

Sure, something like www.example.com/~username mapping to a directory
inside username's home directory isn't that common a pattern these
days, but it used to be _very_ common. And since it's exposed more or
less directly to untrusted network inputs, it's nice to be able to
make the HTTP server drop privileges as much as possible.

This generalizes to any process having reason to descend into a
directory but not reason to enumerate the contents of the directory it
needs to descend into. Another example would be a process wanting to
manage its own /var/log/$subsystem directory itself; it doesn't need
to do anything to anything in /var/log, it only needs to be able to
descend into its own directory.

Yes, you _can_ do it in other ways. But the above is definitely _one_
way.

--
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Richard

2024-05-19 15:20:01 UTC

Then where does the combination rwx come in here? With read the app knows
the file is there, with write it writes to the file. Question is, where the
necessity would be to know the owner of the file or even the kind. The
logger is supposed to just append text to a file. If it were trying to
append text to something it doesn't have the ownership for, it should just
get an error, as that would ultimately be the case when it tries to write
to the file knowing it doesn't have ownership because the user said so. No
need for further knowledge.

That's how Unix permissions have always worked. In order to access
a file, you need +x permissions on *all* of the directories leading
up to that file, and then appropriate permissions on the file itself.
If you have read permission on a directory but *not* execute permissions,
then the only thing you can do is read the contents of that directory --
the filenames and their inode numbers. You cannot stat() the files,
so you can't see who owns them or even what kind of files they are.
Just their names.
If you have execute permission but *not* read permission on a directory,
then you can access the files within the directory, but only if you
already know their names. You can't read the directory to get their
names.
Likewise, write permission on a directory allows you to rename or unlink
files contained within that directory (because the names are not a
property of the files -- they are part of the *directory*). You don't
need write permission on a file to unlink it. Only on the directory.

Greg Wooledge

2024-05-19 15:40:01 UTC