From owner-freebsd-questions Mon Jul 1 09:25:11 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07754 for questions-outgoing; Mon, 1 Jul 1996 09:25:11 -0700 (PDT) Received: from twwells.com (twwells.com [199.79.159.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA07749 for ; Mon, 1 Jul 1996 09:25:05 -0700 (PDT) Received: by twwells.com (Smail3.1.29.1 #8) id m0ualmS-0001BNC; Mon, 1 Jul 96 12:24 EDT To: freebsd-questions@freebsd.org From: bill@twwells.com (T. William Wells) Subject: Re: a talkd/write improvement I made Date: 1 Jul 1996 12:24:54 -0400 Lines: 38 Message-ID: <4r8u4m$9k5@twwells.com> References: <4qur3j$qr0@twwells.com> <199606280115.BAA09748@jraynard.demon.co.uk> NNTP-Posting-Host: localhost.twwells.com Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199606280115.BAA09748@jraynard.demon.co.uk>, James Raynard wrote: : > : How about *not* allowing the write if .talkrc exists but is : > : unreadable? That way, I can make my .talkrc readable by a group that : > : represents, for example, people working on the same project, and use : > : it to filter them more selectively, while shutting everyone else out. : > : > That doesn't resolve the problem. The usual problem is people : > protecting their home directories. Then, I can't tell if they : > have a .talkrc. : : Actually, you can if you check errno (if it doesn't exist, you get : ENOENT, if it exists but you don't have permission, you get EACCESS). Actually, that's total BS. If the directory does not have permissions are, e.g., 700, you can't check it _at all_. : > Also, your suggestion isn't going to do much for talkd.... : : Not sure I follow you. Since talkd runs as root, it will be able to : read the file whatever the permissions on the path components are, : won't it? Right. But in the case of talkd, you have a wider range of possible requestors; it includes people not on your machine. Thus, and this isn't all that atypical, if some of the people working on the same project aren't on your machine, they're unable to talk to you. The only advantage of your suggestion is that it allows the specification of the group to be done at one place, in the /etc/group file. Be that as it may, were I do do this, it would not be by means of the group of the file, it would be by means of a special syntax in the file to specify groups. That way, you could allow talk from multiple groups.