[pfx] Re: No Permissions To TLS Certificates

On 2023-10-12 at 08:26:40 UTC-0400 (Thu, 12 Oct 2023 23:26:40 +1100) Matthew J Black via Postfix-users is rumored to have said: On 12/10/2023 23:19, Wietse Venema via Postfix-users wrote: If the 'find' command cannot enumerate mode 755 directories, then this is no longer a problem that receive

[pfx] Re: No Permissions To TLS Certificates

Matthew J Black via Postfix-users: > On 12/10/2023 23:19, Wietse Venema via Postfix-users wrote: > > If the 'find' command cannot enumerate mode 755 directories, then > > this is no longer a problem that receives Postfix support. > > > > Turning off SeLinux is easy. > > Thanks for getting back to

[pfx] Re: No Permissions To TLS Certificates

On 12/10/2023 23:19, Wietse Venema via Postfix-users wrote: If the 'find' command cannot enumerate mode 755 directories, then this is no longer a problem that receives Postfix support. Turning off SeLinux is easy. Wietse Thanks for getting back to me. Yes, turning off SELinux is eas

[pfx] Re: No Permissions To TLS Certificates

duluxoz via Postfix-users: > (Sorry, can't remember if I should be top-posting or bottom-posting :-)? ) > > The answer for both queries: > > * The root folder is 555 root:root > * All other folders are 755 root:root > * The certs themselves are 600 root:root (I think I mentioned this one >

[pfx] Re: No Permissions To TLS Certificates

(Sorry, can't remember if I should be top-posting or bottom-posting :-)  ) The answer for both queries: * The root folder is 555 root:root * All other folders are 755 root:root * The certs themselves are 600 root:root (I think I mentioned this one in my original post - I think) Having rai

[pfx] Re: No Permissions To TLS Certificates

duluxoz via Postfix-users: > Oct 11 17:33:05 mail.me.local email_postfix[2038]: find: > '/etc/postfix/./certs/me.local.pem': Permission denied > Oct 11 17:33:05 mail.me.local email_postfix[2039]: postfix/postlog: > warning: not owned by root: /etc/postfix/./certs/me.local.pem What is the output

[pfx] No Permissions To TLS Certificates

ver for our internal websites - so that's all good (as far as I can determine). These Certificates (in .pem format) are placed in the "/etc/postfix/certs/" folder. The folder and the certificates have ownership of root:root and permissions of 0755/0600 respectively. T

[pfx] Re: postfix database, aliases, permissions, configuration issue, help requested, perplexed

David Mehler via Postfix-users: > Hello, > > Thanks everyone for the feedback. > > I've commented out proxy_read_maps which seems to have done it, > postfix/local isn't trying to get in to things and aliases are > working, though I'm not sure if the perms there are right, 755 > root:root on /etc/

[pfx] Re: postfix database, aliases, permissions, configuration issue, help requested, perplexed

Hello, Thanks everyone for the feedback. I've commented out proxy_read_maps which seems to have done it, postfix/local isn't trying to get in to things and aliases are working, though I'm not sure if the perms there are right, 755 root:root on /etc/postfix/sql and 644 root:root on the various .cf

[pfx] Re: postfix database, aliases, permissions, configuration issue, help requested, perplexed

On Thu, Jul 20, 2023 at 08:45:46AM -0400, David Mehler via Postfix-users wrote: > Thank you for your reply. My apologies, I thought these issues were > all possibly interrelated. > > To the first issue the postfix process dying. Quite possibly, the right formulation is "exiting as expected", rat

[pfx] Re: postfix database, aliases, permissions, configuration issue, help requested, perplexed

On Wed, Jul 19, 2023 at 11:23:53PM -0400, Viktor Dukhovni via Postfix-users wrote: > > #systemctl status postfix > > ? postfix.service - Postfix Mail Transport Agent > > Loaded: loaded (/lib/systemd/system/postfix.service; enabled; preset: > > e> > > Active: active (exited) since Wed 20

[pfx] Re: postfix database, aliases, permissions, configuration issue, help requested, perplexed

check" I get no warnings. I checked for both selinux and apparmor neither is installed. I ran "postfix set-permissions" again no warnings. I hope this information helps. Thanks. Dave. On 7/19/23, Viktor Dukhovni via Postfix-users wrote: > On Wed, Jul 19, 2023 at 06:03:17PM -040

[pfx] Re: postfix database, aliases, permissions, configuration issue, help requested, perplexed

On Wed, Jul 19, 2023 at 06:03:17PM -0400, David Mehler via Postfix-users wrote: > I'm trying to migrate to a new setup, Debian 12 with Postfix 3.7 and > Dovecot 2.3 using virtual mailbox domains. There are no local everyone > is virtual. The first problem I'm seeing is the Postfix process is > exi

[pfx] postfix database, aliases, permissions, configuration issue, help requested, perplexed

ything wouldn't be working since domains.cf can't be found then receiving any email shouldn't work, sent a test message through and it does, if I send to a non-aliases address i.e. r...@domain.com does not work, yet u...@domain.com goes through just fine. Here's my master.cf file and

[pfx] Re: milter-greylist, run-as and permissions on freebsd

ilter-greylist.sock > > The directory and the socket file were originally rwxr-xr-x > permissions. I had to change them to group writeable to get the > milter to work. > > Is this the proper way to set this up? Executable sockets? I don't think so. Socket permission

[pfx] milter-greylist, run-as and permissions on freebsd

/ drwxrwxr-x 2 mailnull mailnull 512 May 23 19:27 /var/milter-greylist/ $ ls -l /var/milter-greylist/milter-greylist.sock srwxrwxr-x 1 mailnull mailnull 0 May 22 16:43 /var/milter-greylist/milter-greylist.sock The directory and the socket file were originally rwxr-xr-x permissions. I had to

[pfx] Re: maillog_file is unintentionally? created with 600 permissions

David Roe via Postfix-users: > I was doing some work with postfix logrotation as part of a recent > project and ran across what seems to be unintended behavior. > > When running postfix logrotate the maillog_file is created with > 600 permissions which was tripping up a log tail

[pfx] maillog_file is unintentionally? created with 600 permissions

I was doing some work with postfix logrotation as part of a recent project and ran across what seems to be unintended behavior. When running postfix logrotate the maillog_file is created with 600 permissions which was tripping up a log tail system of ours. I'm working on the log tailer,

Re: Setting group permissions on new mail

> On 30 Jun 2022, at 15:40, Wietse Venema wrote: > > Felix Ingram: >> Hello all, >> >> Is it possible to set group read permissions on delivered mail? I'm using >> virtual to deliver mail to a local maildir and have set a static uid and >> gid.

Re: Setting group permissions on new mail

On 30.06.22 14:10, Felix Ingram wrote: Is it possible to set group read permissions on delivered mail? I'm using virtual to deliver mail to a local maildir and have set a static uid and gid. I would then like a separate process to read the mail but this runs as a different uid/user. the

Re: Setting group permissions on new mail

Felix Ingram: > Hello all, > > Is it possible to set group read permissions on delivered mail? I'm using > virtual to deliver mail to a local maildir and have set a static uid and > gid. I would then like a separate process to read the mail but this runs as > a different

Setting group permissions on new mail

Hello all, Is it possible to set group read permissions on delivered mail? I'm using virtual to deliver mail to a local maildir and have set a static uid and gid. I would then like a separate process to read the mail but this runs as a different uid/user. I have added the user to a the same

Re: $queue_directory/private permissions

improvement to me. That's what >> I wanted to validate with the mailing list. > > Sorry, that breaks the Postfix internal access control model in unsupported > ways. Root needs to be able to read the directory with its standard > permissions. OK, thank you. Regards, Simon

Re: $queue_directory/private permissions

Bastian Blank: > On Mon, Mar 25, 2019 at 01:32:28AM -0400, Viktor Dukhovni wrote: > > Sorry, that breaks the Postfix internal access control model in unsupported > > ways. Root needs to be able to read the directory with its standard > > permissions. > > How exactly

Re: $queue_directory/private permissions

On Mon, Mar 25, 2019 at 01:32:28AM -0400, Viktor Dukhovni wrote: > Sorry, that breaks the Postfix internal access control model in unsupported > ways. Root needs to be able to read the directory with its standard > permissions. How exactly does "root" get permissions to read t

Re: $queue_directory/private permissions

e Postfix internal access control model in unsupported ways. Root needs to be able to read the directory with its standard permissions. -- Viktor.

Re: $queue_directory/private permissions

ith the >> same owner/group. > > Sorry, changes to Postfix permissions are not supported. > > You are welcome to configure AppArmor etc. so that they will not > break legitimate operation of Postfix, but such configuration is > considered platform-specific, and outside the sc

Re: $queue_directory/private permissions

On 2019-03-24 6:02 p.m., Viktor Dukhovni wrote: >> On Mar 24, 2019, at 4:33 PM, Simon Deziel wrote: >> >> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I >> noticed the tlsproxy process is apparently trying to connect to tlsmgr's >> Unix socket while still running as root. > >

Re: $queue_directory/private permissions

> On Mar 24, 2019, at 4:33 PM, Simon Deziel wrote: > > I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I > noticed the tlsproxy process is apparently trying to connect to tlsmgr's > Unix socket while still running as root. The premise is false. On all the systems I've used, the

Re: $queue_directory/private permissions

Simon Deziel: > I can think of 2 ways to workaround this. One is to tell Apparmor to > grant the tlsproxy process the needed capability and the other is to > have the $queue_directory/private directory perms set to 0710 with the > same owner/group. Sorry, changes to Postfix permiss

$queue_directory/private permissions

Hello, I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I noticed the tlsproxy process is apparently trying to connect to tlsmgr's Unix socket while still running as root. Since tlsmgr's socket is stored under $queue_directory/private that has perms set to 0700 and owned by postfi

Re: set-permissions fails: how to fix and/or manual set correct permissions?

> On Sep 30, 2018, at 2:51 PM, Max Mustermann wrote: > > Usually it's a mistake to test if the user is root. > POSIX does not even require a root user. This is not a productive discussion... The Postfix deployment scripts reasonably expect to be able to chown files to "root", or check whether t

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Usually it's a mistake to test if the user is root. POSIX does not even require a root user. source: On 30-09-18 19:36, Viktor Dukhovni wrote: Postfix documentation is not the POSIX specification. On systems that devi

Re: set-permissions fails: how to fix and/or manual set correct permissions?

> On Sep 30, 2018, at 1:26 PM, Max Mustermann wrote: > > How should I know that postfix requires the super-user to have "root" as name? > > I don't see this information in the README, neither in the (file system) > requirements. Some assumptions are inevitably so basic that they're not written

Re: set-permissions fails: how to fix and/or manual set correct permissions?

How should I know that postfix requires the super-user to have "root" as name? I don't see this information in the README, neither in the (file system) requirements. Or can't I read? On 30-09-18 18:24, Wietse Venema wrote: Max Mustermann: # postfix set-permissions fin

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Max Mustermann: > # postfix set-permissions > find: unknown user root WTF? > # ls -lah /opt/sbin/postdrop > -rwxr-xr-x1 NewRootUser root 246.8K Postfix requires a standard environment, with a user called "root" who has super-user privileges, with UID zero and GI

set-permissions fails: how to fix and/or manual set correct permissions?

ry = no myhostname = domain.nl mynetworks = 1.1.2.1,8.9.1.1 queue_directory = /opt/var/spool/postfix shlib_directory = /opt/lib/postfix smtputf8_enable = no unknown_local_recipient_reject_code = 550 # postfix set-permissions find: unknown user root # ls -lah /opt/sbin/postdrop -rwxr-xr-x1 NewR

Heads up for Gentoo users: mail-mta/postfix-3.3.1-r1 has permissions problems

For anyone using Postfix on Gentoo, be aware that mail-mta/postfix-3.3.1-r1 installs with many incorrect file permissions that result in impaired functionality (specifically, postdrop won't work). You may want to consider rolling back to 3.2.4 until the ebuild is fixed. If you want to jus

Re: 3.4-20180605-nonprod tlsproxy permissions

Noel Jones: > On 6/13/2018 11:19 AM, Viktor Dukhovni wrote: > > > > > >> On Jun 13, 2018, at 12:09 PM, Noel Jones wrote: > >> > >> Maybe tlsproxy is dropping permissions too soon? > > > > Because it serves multiple SMTP delivery agents,

Re: 3.4-20180605-nonprod tlsproxy permissions

On 6/13/2018 11:19 AM, Viktor Dukhovni wrote: > > >> On Jun 13, 2018, at 12:09 PM, Noel Jones wrote: >> >> Maybe tlsproxy is dropping permissions too soon? > > Because it serves multiple SMTP delivery agents, with > potentially different client certs, it ca

Re: 3.4-20180605-nonprod tlsproxy permissions

> On Jun 13, 2018, at 12:09 PM, Noel Jones wrote: > > Maybe tlsproxy is dropping permissions too soon? Because it serves multiple SMTP delivery agents, with potentially different client certs, it can't obtain the certs in advance. The solution is to serialize the client ce

3.4-20180605-nonprod tlsproxy permissions

cate_chain_file:system lib:ssl_rsa.c:722: Jun 13 10:53:29 mgate3 postfix/smtp[93494]: warning: private/tlsproxy service role "client" is not available Temporarily making the cert world-readable clears the error and allows connection reuse. Maybe tlsproxy is dropping permissions too soon? -- Noel Jones

Re: Upgrade to -3.2.5: permissions question

best case is when you don't really need to do the recursive chown at > all. Since we have > > $queue_directory:d:root:-:755:uc Unfortunately, the recursion is needed, if a new package or a system upgrade changes the mail_owner, with already queued mail then having incorrect ownership. Hence the use o

Re: Upgrade to -3.2.5: permissions question

On 01/29/2018 03:31 PM, Viktor Dukhovni wrote: > > This issue affects a lot more than just Postfix, for example tar(1) > when run as root will chown files to the owner listed in the archive > metadata, and is almost certainly equally exposed. I'm not 100% sure, but it looks like GNU tar will use

Re: Upgrade to -3.2.5: permissions question

postfix -s /bin/sh -c 'ln /etc/passwd >/var/spool/postfix/active/x' > $ sudo postfix set-permissions > $ ls /etc/passwd > -rw-r--r-- 2 postfix root 1.4K 2018-01-27 11:47 /etc/passwd This issue affects a lot more than just Postfix, for

Re: Upgrade to -3.2.5: permissions question

On 01/29/2018 12:25 PM, Joris (ideeel) wrote: > > Doesnt postfix use proxymap for that? > http://www.postfix.org/proxymap.8.html > For what? I'm wondering whether or not the upgrade procedure is safe w.r.t. the $mail_owner user.

Re: Upgrade to -3.2.5: permissions question

On 01/28/2018 01:53 PM, Viktor Dukhovni wrote: > > You're not supposed to do this "by hand". Instead, when upgrading from > source, run: > > # postfix set-permissions upgrade-configuration > How sensitive is the $mail_owner account? From what I gather,

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Wietse Venema wrote: Please tell the maintainer that it they need to run the command, not the user. Wietse, I'll do this. Thanks, Rich

Re: Upgrade to -3.2.5: permissions question

, > >Next upgrade I'll run the set-permissions script. Please tell the maintainer that it they need to run the command, not the user. Wietse

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Wietse Venema wrote: You're not supposed to chown the files. That is part of the Postfix installation/upgrade process. If you use some non-Postfix installation/upgrade procedure, then that is broken. Wietse, Next upgrade I'll run the set-permissions scrip

Re: Upgrade to -3.2.5: permissions question

-permissions Not surprisingly, that bit of advice does not always followed. Viktor, It's been a very long time since I looked at that page and that advice might well have been added since my last visit. I change the version number in the build script and it Just Works. Thanks for pointin

Re: Upgrade to -3.2.5: permissions question

> On Jan 28, 2018, at 2:41 PM, Rich Shepard wrote: > > I use the SlackBuilds.org build script (as I do for all my installations > and upgrades). Please file a bug report for the build scripts in question. When it installs Postfix, it should run "postfix set-permissions&

Re: Upgrade to -3.2.5: permissions question

Rich Shepard: >postdrop still is a group. What I had neglected in my post-installation > notes was to change the group to postdrop for those two scripts prior to > running set-gid on them. You're not supposed to chown the files. That is part of the Postfix installation/upgrade process. If you

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Viktor Dukhovni wrote: Note that "make; make upgrade" would normally take care of this, perhaps you're doing something else (needlessly complicated)? Viktor, I use the SlackBuilds.org build script (as I do for all my installations and upgrades). Also see: http://www

Re: Upgrade to -3.2.5: permissions question

> On Jan 28, 2018, at 2:08 PM, Rich Shepard wrote: > > On Sun, 28 Jan 2018, Viktor Dukhovni wrote: > >> # postfix set-permissions upgrade-configuration Note that "make; make upgrade" would normally take care of this, perhaps you're doing something else (need

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Viktor Dukhovni wrote: # postfix set-permissions upgrade-configuration Viktor, I thought there was a procedure for post-upgrade configuration but had forgotten where I had seen it. Thanks very much for the information. It now resides where I'll see it (and u

Re: Upgrade to -3.2.5: permissions question

in prior upgrades and would appreciate > learning what I need to change to remove them. You're not supposed to do this "by hand". Instead, when upgrading from source, run: # postfix set-permissions upgrade-configuration -- -- Viktor.

RE: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, robert.wo...@robertwolfe.org wrote: I would first check and see if group "postdrop" exists. Then, if so, I would recommend running a "chown root:postdrop" on these files. But, of course, YMMV. Robert, postdrop still is a group. What I had neglected in my post-installati

RE: Upgrade to -3.2.5: permissions question

Of Rich Shepard Sent: Sunday, January 28, 2018 12:12 PM To: postfix-users@postfix.org Subject: Upgrade to -3.2.5: permissions question I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop and /usr/sbin/postqueue were set gid: -rwxr-sr-x 1 root root 13888 Jan 28 08:58 /usr/sbi

Upgrade to -3.2.5: permissions question

I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop and /usr/sbin/postqueue were set gid: -rwxr-sr-x 1 root root 13888 Jan 28 08:58 /usr/sbin/postdrop* -rwxr-sr-x 1 root root 18012 Jan 28 08:58 /usr/sbin/postqueue* Yet, when I start postfix I see these messages: Jan 28

Re: Permissions warning for symlinked script

\ + $FIND $todo \( -perm -020 -o -perm -002 \) \ -exec $WARN group or other writable: {} \; # Check Postfix mail_owner-owned directory tree owner/permissions.

Re: Permissions

ks for the help. On 2016-02-24 6:22 AM, Wietse Venema wrote: John A @ KLaM: Recently there was a discussion about file permissions and ownership. My postfix setup is as far as I know fairly conventional Debian stretch. Run "postfix set-permissions", then "postfix check", and fi

Re: Permissions warning for symlinked script

pf-m...@duboulder.com: > On postfix startup this message is logged: > [postfix-out/postfix-script] warning: group or other writable: > /etc/postfix-out/./gen-dh-params.sh > > Is this expected behavior? This is a multi-instance setup with a common script > in the main config directory. > > # post

Permissions warning for symlinked script

On postfix startup this message is logged: [postfix-out/postfix-script] warning: group or other writable: /etc/postfix-out/./gen-dh-params.sh Is this expected behavior? This is a multi-instance setup with a common script in the main config directory. # postconf mail_version mail_version = 3.0.3

Re: Permissions

John A @ KLaM: > Recently there was a discussion about file permissions and ownership. > My postfix setup is as far as I know fairly conventional Debian stretch. Run "postfix set-permissions", then "postfix check", and fix any permission problems that it reports. If a

Re: Permissions

John, you might want to play around with a script I started a while ago. I don't recall if I finished it. I think it did the job well enough to stop working on it at that time. p@rick * John A @ KLaM : > Recently there was a discussion about file permissions and ownership. > My po

Permissions

Recently there was a discussion about file permissions and ownership. My postfix setup is as far as I know fairly conventional Debian stretch. /etc/postfix root root 755 Main.cf root root 644 Master.cf root root 644 /etc/postfix/maps root root 755 Map, pcre etc root root 644 /etc/postfix/sasl

Re: SV: SV: access permissions 101

On 20/02/16 11:02, Sebastian Nielsen wrote: > Think like a apartment. Your outer door is of course closed and locked, but > your inner doors are always open. We leave it at "agree to disagree". To me your comparison tells me what the problem is. It also doesn't take the inhabitants into account.

SV: SV: access permissions 101

I need to separate things for security reasons, I rather put them on separate networks in firewall with strict rules in-between, rather than fiddling with permissions and getting that things working. So I think its just another way to administrate a server. Some people prefer average security every

Re: SV: access permissions 101

ains is something super-sensitive. > > > -Ursprungligt meddelande- > Från: Jim Reid [mailto:j...@rfc1035.com] > Skickat: den 20 februari 2016 01:40 > Till: Sebastian Nielsen > Kopia: postfix-users@postfix.org > Ämne: access permissions 101 > > >> On 19 F

Re: SV: access permissions 101

On 02/19/2016 08:05 PM, Sebastian Nielsen wrote: > > Yeah, I agree that actually, only 644 is required on that config > file. But why get so angry when someone 666's a file to just get > things working? Its not like a list of banned spam domains is > something super-sensitive. > Maybe this makes

SV: access permissions 101

x27;s a file to just get things working? Its not like a list of banned spam domains is something super-sensitive. -Ursprungligt meddelande- Från: Jim Reid [mailto:j...@rfc1035.com] Skickat: den 20 februari 2016 01:40 Till: Sebastian Nielsen Kopia: postfix-users@postfix.org Ämne: ac

access permissions 101

't really "world writable", > since only you have a account on the server anyways. This is a remarkably stupid and utterly irresponsible thing to say. It’s also wrong. Very, very wrong. One of the fundamental principles of security is least privilege. Things get the minimum permissions

Re: Folder permissions problem, /var/spool/postfix/private

Okay, thanks to all. I moved the milter sockets away from the private/ folder to var/run//.sock, and everything works now with the correct permissions after "postfix set-permissions". Robert Am Dienstag, den 18.08.2015, 13:41 +0200 schrieb Robert Senger: > Hi all, > > I jus

Re: Folder permissions problem, /var/spool/postfix/private

Wietse Venema: > Robert Senger: > > Hi all, > > > > I just upgraded a server from Debian Wheezy to Jessie, and moved the > > system partition to a new, bigger harddisk. Now I am having trouble with > > the permissions of the /var/spool/postfix/private folder. >

RE: Folder permissions problem, /var/spool/postfix/private

: dinsdag 18 augustus 2015 13:42 >Aan: postfix-users@postfix.org >Onderwerp: Folder permissions problem, /var/spool/postfix/private > >Hi all, > >I just upgraded a server from Debian Wheezy to Jessie, and moved the >system partition to a new, bigger harddisk. Now I am having >

Re: Folder permissions problem, /var/spool/postfix/private

Robert Senger: > Hi all, > > I just upgraded a server from Debian Wheezy to Jessie, and moved the > system partition to a new, bigger harddisk. Now I am having trouble with > the permissions of the /var/spool/postfix/private folder. To fix Postfix file permissions: # postfix set-

Folder permissions problem, /var/spool/postfix/private

Hi all, I just upgraded a server from Debian Wheezy to Jessie, and moved the system partition to a new, bigger harddisk. Now I am having trouble with the permissions of the /var/spool/postfix/private folder. As far as I can see all folder permissions throughout the whole system are the same as

Re: Ownership/Permissions of /var/spool/postfix

Wietse Venema: > Rich Shepard: > >During the most recent upgrade I inadvertently altered owner, group, > > and/or permissions in /var/spool/postfix. I've looked for information in all > > the README files that seemed applicable but have not found a list of

Re: Ownership/Permissions of /var/spool/postfix

Rich Shepard: >During the most recent upgrade I inadvertently altered owner, group, > and/or permissions in /var/spool/postfix. I've looked for information in all > the README files that seemed applicable but have not found a list of how > /var/spool/postfix subdirector

Re: Ownership/Permissions of /var/spool/postfix

On Thu, 6 Aug 2015, Viktor Dukhovni wrote: # postfix set-permissions Except on Debian systems where it might not work, because the Debian "postfix-files" file (in $daemon_directory for recent enough releases) often has more files list than are actually deployed by Postfix packages

Re: Ownership/Permissions of /var/spool/postfix

On Thu, Aug 06, 2015 at 11:02:46AM -0700, Rich Shepard wrote: > I want a list of owners, groups, and permissions I can keep here so I can > repair inadvertent changes during future upgrades. # postfix set-permissions Except on Debian systems where it might not work, because the

Re: Ownership/Permissions of /var/spool/postfix

On Thu, 6 Aug 2015, Michael J Wise wrote: This is from a MacOS 10.9 instance, so it's not quite current, and the user is ... a bit weird, but it should help as a data point. Good luck! Thanks, Michael. Rich

Re: Ownership/Permissions of /var/spool/postfix

> On Thu, 6 Aug 2015, Michael J Wise wrote: > >> Needs Group Write. > > Michael, > >Ah, I should have seen that. > >> See that little "s"? >> That's special. > >Yep. I learned that maildrop and public need to be set gid. > >It would still be useful to have a complete list of owners, gr

Re: Ownership/Permissions of /var/spool/postfix

On Thu, 6 Aug 2015, Michael J Wise wrote: Needs Group Write. Michael, Ah, I should have seen that. See that little "s"? That's special. Yep. I learned that maildrop and public need to be set gid. It would still be useful to have a complete list of owners, groups, and perms for the

Re: Ownership/Permissions of /var/spool/postfix

>During the most recent upgrade I inadvertently altered owner, group, > and/or permissions in /var/spool/postfix. I've looked for information in > all > the README files that seemed applicable but have not found a list of how > /var/spool/postfix subdirectories should be

Ownership/Permissions of /var/spool/postfix

During the most recent upgrade I inadvertently altered owner, group, and/or permissions in /var/spool/postfix. I've looked for information in all the README files that seemed applicable but have not found a list of how /var/spool/postfix subdirectories should be set. Please point me to

Re: Permissions on directories with virtual domains and virtual users?

irtual, delay=0.15, delays=0.1/0.01/0/0.04, dsn=4.2.0, >> status=deferred >> (maildir delivery failed: create maildir file >> /var/mail/deltoid.com/jeff/Maildir/tmp/1396518256.P5670.debian-x2: >> Permission denied) >> >> Permissions are as follows: >> >&g

Re: Permissions on directories with virtual domains and virtual users?

r's `home` is `/var/mail//`; and the path > >> to `MailDir` is `/var/mail///MailDir` > >> > >> The mail logs continue to show a *Permission Denied*: > > > > You show PERMISSIONS (owner, group) of files/directories. > > > > What are the PRIV

Re: Permissions on directories with virtual domains and virtual users?

ry failed: create maildir file > /var/mail/deltoid.com/jeff/Maildir/tmp/1396518256.P5670.debian-x2: > Permission denied) > > Permissions are as follows: > > # ls -l /var/mail/ Also "ls -ld /var/mail" and same for /var; either parent directory could block p

Re: Permissions on directories with virtual domains and virtual users?

0/0.04, dsn=4.2.0, >> status=deferred >> (maildir delivery failed: create maildir file >> /var/mail/deltoid.com/jeff/Maildir/tmp/1396518256.P5670.debian-x2: >> Permission denied) >> >> Permissions are as follows: >> >> # ls -l /var/mail/ &g

Re: Permissions on directories with virtual domains and virtual users?

e path >> to `MailDir` is `/var/mail///MailDir` >> >> The mail logs continue to show a *Permission Denied*: > > You show PERMISSIONS (owner, group) of files/directories. > > What are the PRIVILEGES (uid,gid) of the Postfix process that delivers mail? Thanks Wietse.

Re: Permissions on directories with virtual domains and virtual users?

mail logs continue to show a *Permission Denied*: You show PERMISSIONS (owner, group) of files/directories. What are the PRIVILEGES (uid,gid) of the Postfix process that delivers mail? Wietse

Re: Permissions on directories with virtual domains and virtual users?

dsn=4.2.0, status=deferred (maildir delivery failed: create maildir file /var/mail/deltoid.com/jeff/Maildir/tmp/1396518256.P5670.debian-x2: Permission denied) Permissions are as follows: # ls -l /var/mail/ total 96 drw-rws--- 4 vmail vmail 4096 Apr 2 18:19 deltoid.co

Permissions on directories with virtual domains and virtual users?

Apr 3 05:44:16 debian-x2 postfix/virtual[5670]: D6DDD1780100: to=, relay=virtual, delay=0.15, delays=0.1/0.01/0/0.04, dsn=4.2.0, status=deferred (maildir delivery failed: create maildir file /var/mail/deltoid.com/jeff/Maildir/tmp/1396518256.P5670.debian-x2: Permission denied) Permi

Re: Permissions on /etc/postfix files

sendmail > compatible interface? I mean the Postfix sendmail command. When someone calls it from command line, it runs with the permissions of that user. The command must lookup some configuration from main.cf. Thus the requirement to keep it world readable. > > I use a Makefile to ma

Re: Permissions on /etc/postfix files

t; I use a Makefile to maintain maps and permissions: That's quite clever. On 06 Sep 2013, at 03:29 , DTNX Postmaster wrote: > We generally use a subdirectory within '/etc/postfix' to store all > 'custom' files such as maps and the like, and restrict the permissions >

Re: Permissions on /etc/postfix files

On Sep 6, 2013, at 04:39, LuKreme wrote: > All the files in /etc/postfix are 1) owned by root and 2) marked with 644 > permissions. > > I'm not sure this is a good idea (though there are no other users who login > to the shell, there are other users who at least in theor

Re: Permissions on /etc/postfix files

* LuKreme : > All the files in /etc/postfix are 1) owned by root and 2) marked with 644 > permissions. > > I'm not sure this is a good idea (though there are no other users who login > to the shell, there are other users who at least in theory could). > > I did chmod

Permissions on /etc/postfix files

All the files in /etc/postfix are 1) owned by root and 2) marked with 644 permissions. I'm not sure this is a good idea (though there are no other users who login to the shell, there are other users who at least in theory could). I did chmod 600 and chown postfix the mysql_virtual_*_ma

  1   2   3   >