Hi Ken,
> In the "old days", it was common for the mail spool to only be
> writable by group 'mail' (or something similar) and if you did dot
> locking you couldn't create a lock file in the spool directory unless
> your mail program was setgid mail (you can see this code in the
> original MH).
Date:Sun, 09 Jun 2019 20:04:53 -0400
From:Ken Hornstein
Message-ID: <2019061454.ebc8a15c...@pb-smtp2.pobox.com>
| Secondly, I guess it all boils down to the semantics of the real and
| effective userids.
Not entirely, but that's part of it.
| My
Man, I go out of town for a few days and a whole bunch of stuff gets
said on this topic. Responding to various emails ...
>I can not think of one reason why inc shoud be set{g,u}id'ed.
In the "old days", it was common for the mail spool to only be writable
by group 'mail' (or something similar)
Hi Valdis,
> 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
I'm surprised you think I'd allow a non-nmh-user user on this machine.
--
Cheers, Ralph.
--
nmh-workers
Hi Bakul,
> > 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
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
>May be so but this is allowed and getpwuid(geteuid()) will do the wrong
>thing for all but one login id sharing the same uid.
*shrug* I mean, yeah ... but so what? It's allowed, but we already
use getpwuid(getuid()) and we don't get bug reports on it being problem.
>Practically speaking,
On Jun 4, 2019, at 10:08 AM, Ken Hornstein wrote:
>> This fails when there are multiple users with the same uid as getpwuid()
>> will likely fetch the first matching entry. On FreeBSD (& May be other
>> BSDs) getlogin() is a syscall and works correctly without a controlling
>> terminal. But I
On Tue, 04 Jun 2019 13:08:43 -0400, Ken Hornstein said:
> True story: a long time ago we had a number of IRIX systems. The inetd
> on those systems was buggy so it was common when you changed the inetd
> configuration you just restarted it instead of sending it a HUP signal.
> But even though
>This fails when there are multiple users with the same uid as getpwuid()
>will likely fetch the first matching entry. On FreeBSD (& May be other
>BSDs) getlogin() is a syscall and works correctly without a controlling
>terminal. But I was forgetting about Linux which never disappoints
>in
On Jun 3, 2019, at 8:06 AM, Ken Hornstein wrote:
>
> I am thinking that falling back to getpwuid(getuid()) is the most reasonable
> approach, for the following reasons:
This fails when there are multiple users with the same uid as getpwuid()
will likely fetch the first matching entry. On
>> I am thinking that falling back to getpwuid(getuid()) is the most
>> reasonable approach
>
>I notice that a setuid inc(1) has various troubles due to the use of
>real user ID rather than effective.
Like ... what? I would have though using the real UID would have been the
correct answer.
Hi Ken,
> getusername() (the nmh function) is called by programs like slocal and
> rcvtty, which may not have a controlling terminal and I am unclear
> what LOGNAME would mean in their environment as well.
True. cron(8) here sets $LOGNAME, but does .forward, etc?
> I am thinking that falling
>That seems worse. Linux's getlogin(3) says in Description that $LOGNAME
>is often more useful, and its Bugs section is an amusing read.
>getlogin(3p) from POSIX is also available for detail.
I'm not so crazy on using getlogin() since this function can be called
by nmh programs that do not have
Hi Bakul,
> > Should we simplify the code to demand $LOGNAME exists and use that?
>
> You can use getlogin(3) or getlogin_r(3) as per ISO/IEC 9945-1:1996.
That seems worse. Linux's getlogin(3) says in Description that $LOGNAME
is often more useful, and its Bugs section is an amusing read.
On Mon, 03 Jun 2019 09:08:16 +0100 Ralph Corderoy wrote:
> Hi Ken,
>
> > > /var/mail/$USER Location of the system mail drop.
> >
> > But we don't actually use $USER (we call getpwuid(getuid()) and use
> > that).
>
> And even then it's not that simple.
>
> > I personally interpreted the use of
Hi Ken,
> > /var/mail/$USER Location of the system mail drop.
>
> But we don't actually use $USER (we call getpwuid(getuid()) and use
> that).
And even then it's not that simple.
> I personally interpreted the use of $USER as "the username goes here",
> not "we use the value of the $USER
>$HOME/.mh_profile The user's profile.
So, we will use $HOME if it is set.
>/var/mail/$USERLocation of the system mail drop.
But we don't actually use $USER (we call getpwuid(getuid()) and use that).
I personally interpreted the use of $USER as "the username goes here",
not "we
Bakul wrote:
> Er... that is what the inc man page says!
>/var/mail/$USER Location of the system mail drop.
> But I don't understand why it didn't just follow unix conventions as most
> users
> of MH have been on Unix.
I think it's fine the way it is now (or maybe I'm missing
> On Jun 2, 2019, at 3:15 AM, Ralph Corderoy wrote:
>
> Hi Bakul,
>
>> Looks like inc pays attention to $MAILDROP and if it is not set and
>> profile entry MailDrop is not set, it looks into /var/mail/$USER.
>
> That's pretty much right.
>
>> Not sure if it ever checks $MAIL or $MAILPATH.
>
Hi Bakul,
> Looks like inc pays attention to $MAILDROP and if it is not set and
> profile entry MailDrop is not set, it looks into /var/mail/$USER.
That's pretty much right.
> Not sure if it ever checks $MAIL or $MAILPATH.
It doesn't, and it doesn't use $USER, or $LOGNAME, either.
inc(1) says
On Sat, 01 Jun 2019 18:51:35 -0700, Bakul Shah said:
> If you are calling procmail from ~/.forward, mail may not be
> left in your system mailbox
Also true if you've configured your system to skip a step and invoke
procmail as the local delivery agent directly
pgp1hCsM6HcIT.pgp
Description:
On Sat, 01 Jun 2019 09:17:16 -0500 "Martin McCormick"
wrote:
> I recently worked on my Debian box and mail began stacking up
> from cron jobs that were erroring out because I had temporarily
> removed the normal shell environment I use so I began getting the
> "you have new mail" message which
Martin wrote:
> I certainly can read the messages if I type mail but I
> seem to recall one can type the inc command and all those
> messages will slurp right in to nmh.
Yes, that should work. I'd check to see what switches, if any,
you're passing to inc (inc -help will show them).
>
I recently worked on my Debian box and mail began stacking up
from cron jobs that were erroring out because I had temporarily
removed the normal shell environment I use so I began getting the
"you have new mail" message which happens when the system checks
your mail queue as the shell prompt
32 matches
Mail list logo
