Re: [nmh-workers] Stupid 'pick' question...
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 go through the > body by default as well still a good idea? Maybe having a separate -searchbody > would be better? The bigger issue is that -search seems to blindly match the msg body. It doesn't even do mime decoding. So for example the body of my prev msg to nmh is base64 encoded (even though it is plain text) and -search fails. Unless I specify a search pattern of encoded text such as 9uIEJpZyBlbmRpYW! -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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 having a separate -searchbody would be better? (Due to events not under my control, I'm currently stuck on a laptop with a Celeron CPU, and disk I/O is painful (it's managing only 3-5Mbytes/sec even with an SSD in it... Ouch) pgpZUdgvZqcDg.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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] net: Fix for_each_netdev_feature on Big endian > [~] scan `pick +linux-kernel 321805 -search 'Subject: \[PATCH [45]\.[0-9]' > -and -from gre...@linuxfoundation.org -list` > 321805 * Thu 21Feb 7k Greg Kroah-Hartma Re: [PATCH 4.9 04/20] > net: Fix for_each_netdev_feature on Big endian < [~] scan `pick +linux-kernel 321805 -search 'Subject: \[WOMBAT [45]\.[0-9]' > -and -from gre...@linuxfoundation.org -list` > pick: no messages match specification > scan: no messages match specification Let us look at what you see (after some cleanup): $ grep ^Subject Mail/linux-kernel/321805 Subject: Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian $ pick +linux-kernel 321805 -search 'Subject: \[PATCH [45]\.[0-9]' -and -from gre...@linuxfoundation.org 321805 $ pick +linux-kernel 321805 -search 'Subject: \[WOMBAT [45]\.[0-9]' -and -from gre...@linuxfoundation.org pick: no messages match specification This makes sense. But note that pick does treat header lines specially. Using your message as an example: $ grep ^Subject: `mhpath cur` Subject: Re: [nmh-workers] Stupid 'pick' question... Subject: Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian The second Subject: line is from the message body. $ pick -subj PATCH cur pick: no messages match specification $ pick -search 'Subject:.*PATH' cur 14 $ pick -search 'Subject:.*nmh' cur 14 So pick runs -search on header lines as well as the body a header specific option is only run against headers. And pick matches header line *after* line folding, as tested with Received: pick --received 'bakul' cur -- matches but my name is not on the same line as Received: pick --received '\]\)' cur -- match )] on the first line pick --received '\]\)$' cur -- no match even though the first Received: line ends wih )] pick --received '0400$' cur -- match as 0400 ends the last line of a Received: field. Conclusion: the man page is not quite accurate! But that is probably ok. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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 seeing, | unless -search is *also* doing a split into component and pattern I haven't looked, but it is not impossible that (perhaps any number of) "Re:" get deleted from Subject headers before matching (or perhaps it attempts a match both with and without) - that shouldn't be needed with a -subject search, but with -search it would allow users to easily find all messages in a thread (with and without Re: stuck in there). I also wouldn't be surpriused to see mailing-list noise elided before matching is attempted (the '[nmh-workers]' that gets installed in all of these messages). I have seen systems in the past which acted like that. It tends to more often DTRT than otherwise (but when it is otherwise, it is certainly perplexing). However, when I try it, I don't see that (either of them) ... jinx$ scan $( pick -subject "Stupid 'pick" +info/nmh ) 11777 Fri "Valdis Kl?tnieks [nmh-workers] Stupid 'pick' question...<<--= 11778 Fri Bakul Shah Re: [nmh-workers] Stupid 'pick' question...
Re: [nmh-workers] Stupid 'pick' question...
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? That is, is anyone, anywhere, going to attempt to match a ^ at the start of a field matching pattern pattern without escaping it (either as \^ or using [^]) ? (Even if they do know that nmh prepends more pattern to the start.) kre -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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 +linux-kernel 321805 -search 'Subject: \[PATCH [45]\.[0-9]' -and -from gre...@linuxfoundation.org -list` 321805 * Thu 21Feb 7k Greg Kroah-Hartma Re: [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian < pgprtuNFrLPxk.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 tools on /var/spool/mail/otheruser, so if they aren't also nmh users they're in trouble pgp7F9QeYBmGh.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 access then it should be the effective > one rather than the real one. Do you agree? I haven't thought about this to be frank because IMHO privilege escalation should be used very very sparingly. My instinct would be to use euid/egid *only* in programs that *are* to be used setuid/setgid. So that a misuse will be caught more quickly. More as a general principle. Your checking From/Subject for another user is not likely to be a common practice. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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. Do you agree? -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 Subject fields.
Probably safer to use "sudo -u another inc" or whatever mh command?
> And I think Ken's point was about all nmh, as was my reply.
Hmm... Same response:-)
Privilege escalation should be done externally.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 my reply.
--
Cheers, Ralph.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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'. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 Welcome to nmh version 1.7+dev See the release notes in /usr/share/doc/nmh/NEWS Send bug reports, questions, suggestions, and patches to nmh-workers@nongnu.org. That mailing list is relatively quiet, so user questions are encouraged. Users are also encouraged to subscribe, and view the archives, at https://lists.gnu.org/mailman/listinfo/nmh-workers This message will not be repeated until nmh is next updated. Press enter to continue: inc: error on folder /home/ralph/mail/inbox: Permission denied $ So it's trying to access my inbox rather than the other user's. Also, both the other user and I have already acknowledged the 1.7+dev welcome message, yet it is shown again. I expect other problems would come to light if I persisted. > I would have though using the real UID would have been the correct > answer. I have permission to access the effective user's files, and not the real user's, then shouldn't those be the ones I'm attempting to access? > 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. :-) -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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 to > match a literal '^'. Which it what happens at the moment, so it wouldn't be backwards compatible. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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 found, remove it, and replace the ".*" that's inserted into the RE with "[ \t]*" ? That would, I suspect, be more useful, and more in accordance with what users might expect to happen. Certainly no-one who uses a leading ^ is expecting it to attempt to match a literal '^'. kre -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Flagging messages
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 https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Stupid 'pick' question...
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 re: -sub foo -and -not --references '_*' -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
