On Jun 8, 2019, at 6:26 PM, Valdis Klētnieks wrote:
>
> On Sat, 08 Jun 2019 17:17:40 -0700, Bakul Shah said:
>>
>> So pick runs -search on header lines as well as the body a header specific
>> option is only run against headers.
>
> In a world of Microsoft Office attachments, is having -search
On Sat, 08 Jun 2019 17:17:40 -0700, Bakul Shah said:
>
> So pick runs -search on header lines as well as the body a header specific
> option is only run against headers.
In a world of Microsoft Office attachments, is having -search go through the
body by default as well still a good idea? Maybe
On Jun 8, 2019, at 11:03 AM, Valdis Klētnieks wrote:
>
> On Fri, 07 Jun 2019 16:19:15 -0700, Bakul Shah said:
>> You can directly use search as follows:
>>
>> -search 'Subject[ \t]:[ \t]*\[PATCH [45]\.[0-9]'
>
> [~] grep ^Subject Mail/linux-kernel/321805
> Subject: Re: [PATCH 4.9 04/20]
Date:Sat, 08 Jun 2019 14:03:12 -0400
From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks"
Message-ID: <13857.1560016992@turing-police>
| I understand why that .* was causing me indigestion. But I'm having a hard
| time matching "pattern is used directly" with what I'm
Date:Sat, 08 Jun 2019 11:04:27 +0100
From:Ralph Corderoy
Message-ID: <20190608100427.4d1c921...@orac.inputplus.co.uk>
| Which it what happens at the moment, so it wouldn't be backwards
| compatible.
No, it wouldn't - but does anyone really think that matters?
On Fri, 07 Jun 2019 16:19:15 -0700, Bakul Shah said:
> You can directly use search as follows:
>
> -search 'Subject[ \t]:[ \t]*\[PATCH [45]\.[0-9]'
[~] grep ^Subject Mail/linux-kernel/321805
Subject: Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian
[~] scan `pick
On Sat, 08 Jun 2019 14:55:01 +0100, Ralph Corderoy said:
> I often switch to another user to see if they've any new email they'd
> like to know about. All I really need for that is setuid inc that scans
> the From and Subject fields.
At which point the other user can't use their preferred mail
On Jun 8, 2019, at 7:52 AM, Ralph Corderoy wrote:
>
> Hi Bakul,
>
>> Privilege escalation should be done externally.
>
> Regardless of whether it's a good idea, since the kernel is using
> effective user and group IDs for testing permissions, if a user ID is
> used to determine what files to
Hi Bakul,
> Privilege escalation should be done externally.
Regardless of whether it's a good idea, since the kernel is using
effective user and group IDs for testing permissions, if a user ID is
used to determine what files to access then it should be the effective
one rather than the real one.
On Jun 8, 2019, at 6:55 AM, Ralph Corderoy wrote:
>
> Hi Bakul,
>
>> I can not think of one reason why inc shoud be set{g,u}id'ed.
>
> I often switch to another user to see if they've any new email they'd
> like to know about. All I really need for that is setuid inc that scans
> the From and
Hi Bakul,
> I can not think of one reason why inc shoud be set{g,u}id'ed.
I often switch to another user to see if they've any new email they'd
like to know about. All I really need for that is setuid inc that scans
the From and Subject fields.
And I think Ken's point was about all nmh, as was
On Jun 8, 2019, at 6:17 AM, Ralph Corderoy wrote:
>
>> Also, I didn't even think we supported that
>
> This is Unix and setuid and setgid is normal. Unless we explicitly rule
> it out in some cases, it's ruled in. :-)
I can not think of one reason why inc shoud be set{g,u}id'ed.
--
Hi Ken,
> But even though the person who did this had su'd to root, some of
> their user environment variables were inherited by their root shell
> and then inherited by inetd
That sounds like user error; they ran `su' rather than the more commonly
wanted `su -'. Similarly today, `sudo -i'.
--
Hi Ken,
> > I notice that a setuid inc(1) has various troubles due to the use of
> > real user ID rather than effective.
>
> Like ... what?
It's simple to copy inc and make it setuid to another user and then run
it.
$ ./inc
Hi kre,
> Maybe it would be possible to look for a leading ^ in the user's
> pattern (for other than -search), and if found, remove it, and replace
> the ".*" that's inserted into the RE with "[ \t]*" ?
Sounds like a good idea.
> Certainly no-one who uses a leading ^ is expecting it to attempt
Date:Sat, 08 Jun 2019 08:45:17 +0100
From:Ralph Corderoy
Message-ID: <20190608074517.a586020...@orac.inputplus.co.uk>
| Bakul answered about the anchors.
Maybe it would be possible to look for a leading ^ in the user's
pattern (for other than -search), and if
Hi,
Arthur wrote:
> In the end, I’ve decided not to accomplish this through nmh but rather
> use Diane Skoll’s remind program. I think it sums my needs better in
> the long run.
That's https://dianne.skoll.ca/projects/remind/
--
Cheers, Ralph.
--
nmh-workers
Hi Valdis,
> pick -from -subject '\[PATCH [45]\.[0-9]'
...
> However, it *also* catches messages of the form 'Subject: Re: [PATCH
> ' which is unacceptable for the use case in question.
Bakul answered about the anchors. Another approach is to rule out
replies.
-sub foo -and -not -sub
18 matches
Mail list logo
