From owner-freebsd-hackers Fri May 4 20:56: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 6AADC37B423; Fri, 4 May 2001 20:56:05 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id B504E3E0B; Fri, 4 May 2001 20:56:04 -0700 (PDT) To: Alfred Perlstein Cc: "William E. Baxter" , hackers@freebsd.org Subject: Re: Getting peer credentials on a unix domain socket In-Reply-To: <20010504203457.V18676@fw.wintelcom.net>; from alfred@freebsd.org on "Fri, 4 May 2001 20:34:57 -0700" Date: Fri, 04 May 2001 20:56:04 -0700 From: Dima Dorfman Message-Id: <20010505035604.B504E3E0B@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > * Dima Dorfman [010504 20:22] wrote: > > > > Just to expand on that a little more (for others on the list), > > consider crontab(1). It's setuid root right now. Obviously that's > > not good. One way of getting rid of that setuid bit is to have > > cron(8) (or another daemon) listen on a world-writable unix domain > > socket, and have crontab(1) just be a user interface which sends the > > information via that socket. With some mechanism to get the > > credentials of the user that connected, this would be possible. > > The silly part of it is that the socket's initial credentials > might be different than the holder's credentials. Perhaps it is silly to a human, but I don't see how it makes much of a difference. I'm assuming you're talking about either fork()/exec() or descriptor passing. I don't mean to sound rude, but if a user is silly enough to forget to close that descriptor before exec'ing an untrusted program, or he passes it to a program that has no business using it, there are bigger problems. OTOH, the user may legitmately want to do that. If the server is concerned about that, it can always use both techniques (this and SCM_CREDS) together. Without using this, however, the server may be vulnerable to a DoS attack. In cron's case, this attack may be in the form of opening lots of connections and not writing anything. It can't refuse duplicate connections from the same user because it doesn't know who's connected until they send something. BTW, I hope I made it clear that this is for *stream sockets*. It's horribly useless on datagram sockets. Just making sure in case that's what you were thinking about. Thanks, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message