Re: security(8) check maildir as well as mailbox permissions
On Wed, Dec 18, 2013 at 08:48:38PM +0100, Jérémie Courrèges-Anglas wrote:
> skin...@britvault.co.uk (Craig R. Skinner) writes:
>
> > On 2013-12-18 Wed 15:54 PM |, Stuart Henderson wrote:
> >> > > > > Check the security of /var/mail/dirs similar to /var/mail/boxes:
> >> > >
> >>
> >> Indeed, but security(8) really reflects things in the base OS,
> >>
> >
> > smtpd.conf(8)
> > deliver to maildir path
> > Mail is added to a maildir. Its location, path, may
> > contain format specifiers that are expanded before use
> >
> >
> > Therefore: ... deliver to maildir /var/mail/%{user.username}
>
> "Therefore"? How so? What's the logic, here?
>
> deliver to maildir path
> Mail is added to a maildir. Its location, path, may
> contain format specifiers that are expanded before use
> (see above). If path is not provided, then ~/Maildir is
> assumed.
>
> You're trying to trick people into doing what you want. That's not
> a very good idea on this mailing-list.
Maybe a plugin based security(8)? If it won't be accepted into base OS
maybe it could be in ports as an alternative (line base OS nginx with
limited features and nginx in ports).
jirib
Re: security(8) check maildir as well as mailbox permissions
skin...@britvault.co.uk (Craig R. Skinner) writes:
> On 2013-12-18 Wed 15:54 PM |, Stuart Henderson wrote:
>> > > > > Check the security of /var/mail/dirs similar to /var/mail/boxes:
>> > >
>>
>> Indeed, but security(8) really reflects things in the base OS,
>>
>
> smtpd.conf(8)
> deliver to maildir path
> Mail is added to a maildir. Its location, path, may
> contain format specifiers that are expanded before use
>
>
> Therefore: ... deliver to maildir /var/mail/%{user.username}
"Therefore"? How so? What's the logic, here?
deliver to maildir path
Mail is added to a maildir. Its location, path, may
contain format specifiers that are expanded before use
(see above). If path is not provided, then ~/Maildir is
assumed.
You're trying to trick people into doing what you want. That's not
a very good idea on this mailing-list.
> OK for the patch then?
http://nelson-haha.com/
> Cheers,
--
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: security(8) check maildir as well as mailbox permissions
On 2013-12-18 Wed 15:54 PM |, Stuart Henderson wrote:
> > > > > Check the security of /var/mail/dirs similar to /var/mail/boxes:
> > >
>
> Indeed, but security(8) really reflects things in the base OS,
>
smtpd.conf(8)
deliver to maildir path
Mail is added to a maildir. Its location, path, may
contain format specifiers that are expanded before use
Therefore: ... deliver to maildir /var/mail/%{user.username}
OK for the patch then?
Cheers,
--
Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
recent bin/ksh changes - the ctype cleanups one
Hi!
I must say, I'm a bit shy about this, so don't rip my head off, I'm
obviously not trying to question Theo's commit. I just came across this
anomaly:
cvs diff -r 1.26 -r 1.27 vi.c
@@ -792,8 +792,9 @@ vi_cmd(int argcnt, const char *cmd)
return -1;
if (*cmd == 'c' &&
(cmd[1]=='w' || cmd[1]=='W') &&
- !isspace(es->cbuf[es->cursor])) {
- while (isspace(es->cbuf[--ncursor]))
+ !isspace((unsigned
char)es->cbuf[es->cursor])) {
+ while ((unsigned char)
+ isspace(es->cbuf[--ncursor]))
;
ncursor++;
}
That last cast, before isspace(es->...), at line 796; Isn't that cast supposed
to be inside the isspace() function, right before es->..., just like in the
line above it?
So like:
--- vi.c.orig 2013-12-18 17:33:03.667236200 +0100
+++ vi.c2013-12-18 17:33:21.810235659 +0100
@@ -793,8 +793,7 @@ vi_cmd(int argcnt, const char *cmd)
if (*cmd == 'c' &&
(cmd[1]=='w' || cmd[1]=='W') &&
!isspace((unsigned
char)es->cbuf[es->cursor])) {
- while ((unsigned char)
- isspace(es->cbuf[--ncursor]))
+ while (isspace((unsigned
char)es->cbuf[--ncursor]))
;
ncursor++;
}
I admit, the bug I was hunting was not present somehow on OpenBSD, just on
Linux, where I am using this ksh with some modifications and some diffs to make
it compile and work on Linux.
Nevertheless this fixed it for me.
Oh, and the bug was when I entered command mode in vi edit mode, then if
I had something like this in my edit buffer:
$ cd /foo/bar
... then escape to command mode, move to the very beginning of the line,
then press 'c' -> 'w' to delete "one word". Then the previous behaviour
was to delete until before the space, and now after these changes it
would delete the space also.
Daniel
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: security(8) check maildir as well as mailbox permissions
On 2013/12/17 17:07, Craig R. Skinner wrote: > On 2013-12-16 Mon 13:15 PM |, Craig R. Skinner wrote: > > On 2013-12-16 Mon 12:22 PM |, Stuart Henderson wrote: > > > On 2013/12/16 12:11, Craig R. Skinner wrote: > > > > Check the security of /var/mail/dirs similar to /var/mail/boxes: > > > > > > Aren't maildirs usually in ~/Maildir? > > > > > > > MTA's can deliver to maildirs in several places. > > > > Postfix example (the trailing slash changes from mbox to maildir format): > > > > $ postconf -h mail_spool_directory > > /var/mail/ > > > > Usually, all user web files are kept in ~/public_html > OpenBSD places them in /var/www/users/$LOGIN > > By keeping all mail in a separately mounted /var/mail partition, > (with simple mutt & dovecot configs) mail only users can have > /var/empty has $HOME, authpf or nologin as $SHELL. > This eliminates SQL or other complicated mail stores for 'virtual' users > > Separate 'black box' servers can be dedicated to mail only duties, > without user shell logins, > > /var/mail can be NFS exported as there are no file locking problems with > maildirs - each message is a unique file. New mail can be delivered > without locking the box. > > Also, an annual dump cycle can be set on /home, > with quarterly/monthly level 0 dumps on /var/mail, > different quotas set on the different partitions. > > Possibilities abound, Indeed, but security(8) really reflects things in the base OS, perhaps a security.local might be worthwhile for custom setups though...
