All,
> calendar.c forks, so there is no need to regain privileges post
> setuid(). I'm kinda with tg in that setres[ug]id() makes the intent
> clearer instead of relying on uid==0 behavior.
FYI I just uploaded a new version of the package.
It turned out setres[ug]id() are not declared in the
Hi,
On Wed, Dec 08, 2021 at 12:11:28PM +, Thorsten Glaser wrote:
> Michael Meskes dixit:
>
> >I did some more testing and it seems this simple patch fixes the issue:
>
> I think you should still include a setgroups(0, NULL) call there.
>
> Personally I’d prefer setres[ug]id() because that
Michael Meskes dixit:
>I did some more testing and it seems this simple patch fixes the issue:
I think you should still include a setgroups(0, NULL) call there.
Personally I’d prefer setres[ug]id() because that makes the intent
more explicit even when the effect is the same, but… I’ll let you
> As
> I understand it, this is the POSIX way. Anyway, I'm going to prepare
> a
> patch.
I did some more testing and it seems this simple patch fixes the issue:
--- calendar.c 2021-12-07 17:53:16.044315761 +0100
+++ calendar.c 2021-12-07 08:59:20.293726904 +0100
@@ -190,6 +190,8 @@
> > Could you elaborate why? I cannot see much of a difference in these
> > when it comes to the topic at hand. Doesn't set[ug]id set all ids
> > to
> > the given one?
>
> No, it only sets one of the three (real, effective and saved) uid/gid
> to the given one; setres[ug]id() is the one that sets
Michael Meskes dixit:
>Could you elaborate why? I cannot see much of a difference in these
>when it comes to the topic at hand. Doesn't set[ug]id set all ids to
>the given one?
No, it only sets one of the three (real, effective and saved) uid/gid
to the given one; setres[ug]id() is the one that
> >Wouldn't using setuid() suffice?
>
> I doubt that. At least change the gid and reset the auxilliary
Sure, make that setuid() and setgid().
> groups vector. But using setres[ug]id() is safer, especially
> considering each instance shells out to cpp(1), which would
> then otherwise be
Michael Meskes dixit:
>Wouldn't using setuid() suffice?
I doubt that. At least change the gid and reset the auxilliary
groups vector. But using setres[ug]id() is safer, especially
considering each instance shells out to cpp(1), which would
then otherwise be suid-user.
bye,
//mirabilos
--
> I did manage to cobble together something that at least switches
> to users properly… search for USE_CUSTOM_USERSWITCH or userswitch in
> http://www.mirbsd.org/cvs.cgi/src/usr.bin/calendar/calendar.c?rev=HEAD
> combined with…
> ...
Wouldn't using setuid() suffice? Yes, I know setusercontext()
Michael Meskes dixit:
>Hmm, not sure what I'm doing wrong. Using the same entries in my calendar file
>I get:
>
>michael@feivel:~$ calendar
Right, but do enable the cronjob. “calendar -a” runs as root.
Or try sudo calendar -a which is basically the same then watch
your mail. (You’ll also need
[Sorry, I have missed this bug report, didn't make it into the correct mailbox
locally it seems.]
On Mon, Nov 01, 2021 at 12:02:48AM +, Thorsten Glaser wrote:
> #define·ssh·Nov·01→ ssh
> #include·"/root/.ssh/authorized_keys"
Hmm, not sure what I'm doing wrong. Using the same entries in
Dixi quod…
>contents of files that start with a cpp-able string *and* contain
>a tab somewhere after that (because calendar(1) does not call cpp(1)
>with -traditional-cpp, which is another minor bug in the port), but
I was mistaken, it does call it like that, and it does work:
Package: calendar
Version: 12.1.7+nmu3
Severity: serious
Tags: security
Justification: security
X-Debbugs-Cc: t...@mirbsd.de, Debian Security Team
I was wondering how Debian’s calendar(1) packaging handled the
setusercontext(3) part, and after finding d/p/calendar_cap.diff
I see it just… does
13 matches
Mail list logo
