Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #269459 > unrolled thread

Re: Dovecot correct ownership for logs

Back to article view | Back to linux.debian.user

Contents

  Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-19 17:00 +0200
    Re: Dovecot correct ownership for logs Greg Wooledge <greg@wooledge.org> - 2024-05-19 17:10 +0200
      Re: Dovecot correct ownership for logs Stefan Monnier <monnier@iro.umontreal.ca> - 2024-05-19 17:20 +0200
        Re: Dovecot correct ownership for logs Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-05-19 18:30 +0200
      Re: Dovecot correct ownership for logs Richard <rrosner5@gmail.com> - 2024-05-19 17:20 +0200
        Re: Dovecot correct ownership for logs Greg Wooledge <greg@wooledge.org> - 2024-05-19 17:40 +0200

#269459 — Re: Dovecot correct ownership for logs

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [next] | [standalone]

#269460

On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#269461

> 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.

> 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

[toc] | [prev] | [next] | [standalone]

#269464

On 19 May 2024 11:11 -0400, from monnier@iro.umontreal.ca (Stefan Monnier):
>> 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.

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?”

[toc] | [prev] | [next] | [standalone]

#269462

[Multipart message — attachments visible in raw view] — view raw

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.

Am So., 19. Mai 2024 um 17:04 Uhr schrieb Greg Wooledge <greg@wooledge.org>:

> On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote:
> > 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.
>
>

[toc] | [prev] | [next] | [standalone]

#269463

On Sun, May 19, 2024 at 05:15:40PM +0200, Richard wrote:
> 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.

Stop trying to reason out WHY things are the way they are.  Just accept it.

You need execute permission on a directory in order to access anything
within that directory.  That's how it is.  That's the decision the
creators of Unix came up with.

In order for a program to write (append) to a file that already exists,
it needs:

 * execute permission on every directory leading up to that file
 * write permission on the file

If the file does NOT already exist, then the program needs to be able to
create it, and in that case, it will need:

 * execute permission on every directory leading up to where the file goes
 * write permission on the final (leaf) directory

File creation, file removal, and file renaming are directory operations,
and they need write (plus execute, of course) permission on the directory.

Modifying an existing file is a file operation, so that needs write
permission on the file (plus execute permission on the directory).

In EVERY case, you always need execute permission on all the parent
directories as well.  This is well-understood, so we usually don't bother
saying it explicitly.

Kudos to whoever you spoke with on the Dovecot list who thought to go
all the way back to first principles on this one.  We got distracted
with all of the other complex ways that this setup could have been
incorrect, and forgot to check one of the most basic ones.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web