From owner-freebsd-questions Sat Aug 8 09:48:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA00418 for freebsd-questions-outgoing; Sat, 8 Aug 1998 09:48:39 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from lucy.bedford.net (lucy.bedford.net [206.99.145.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA00400 for ; Sat, 8 Aug 1998 09:48:27 -0700 (PDT) (envelope-from djv@lucy.bedford.net) Received: (from djv@localhost) by lucy.bedford.net (8.8.8/8.8.8) id MAA00998; Sat, 8 Aug 1998 12:47:52 -0400 (EDT) (envelope-from djv) Message-Id: <199808081647.MAA00998@lucy.bedford.net> Subject: Re: Weird /home problem resolved [MAYBE] (LONG) In-Reply-To: from Doug White at "Aug 7, 98 01:47:58 pm" To: dwhite@resnet.uoregon.edu (Doug White) Date: Sat, 8 Aug 1998 12:47:52 -0400 (EDT) Cc: djv@bedford.net, sno@teardrop.org, freebsd-questions@FreeBSD.ORG Reply-To: djv@bedford.net From: djv@bedford.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug White wrote > > On Fri, 7 Aug 1998, CyberPeasant wrote: > > > James Snow wrote: > > > > > > Well, I fixed the problem. > > > > > > Two of the people with whom I conversed about this problem could not > > > replicate it on 2.2.6-RELEASE, while I was getting it on 2.2.7-STABLE and > > > 3.0-SNAP. > > > > > > So, I replaced our /usr/bin/login with /usr/bin/login from 2.2.6 and > > > voila, no more login problem. > > > > > > I can only assume then that there was a change made to this program or to > > > one of the library functions that it calls between 2.2.6-RELEASE and one > > > of the more recent releases. > > > > > > I'd be interested in knowing if anyone else can confirm this behaviour and > > > fix it in a similar fashion. > > > > > > > Big HMMM. do you have the 2.2.7 source for login handy? Email it > > to me and I'll stare at it. > > Oof, this may be a bug. Here's the log entry for the one change between > 2.2.6 and 2.2.7 for login.c: > > 1.12.2.10 Thu Apr 30 16:52:31 1998 UTC by peter > CVS Tags: RELENG_2_2_7_RELEASE; Branch: RELENG_2_2 > Diffs to 1.12.2.9 ; Diffs to 1.34 > > MFC: euid flip while accessing home directory early to get to .login_cap > and to be able to chdir() on NFS served homes without root read access. Yup. This is a thorny issue, NFS complicates it. To summarize: (let the user be 'dork', and his home dir /home/dorkhome/dork). (dork is a member of group buggy, and that's dork's only group membership). Login6: chdirs as root.wheel. login7 (unfixed) chdirs as dork.wheel login7f (fixed) chdirs as dork.buggy In the table read "r-x(o)" as "has r-x permission through the 'o' field". As seen by root dork login6 login7 login7f / 755 root.wheel rwx r-x(o) rwx r-x(g) r-x(o) /home 755 root.wheel rwx r-x(o) rwx r-x(g) r-x(o) /home/dorkhome 750 root.buggy rwx r-x(g) rwx --- r-x(g) /home/dorkhome/dork 700 dork.buggy rwx(r) rwx rwx(r) rwx rwx In the case of NFS with maproot=nobody, this permission scheme becomes: (root = nobody.wheel, I think. NFS dirs are marked *) / 755 root.wheel rwx r-x(g) rwx r-x(g) r-x(o) /home 755 root.wheel rwx r-x rwx r-x(g) r-x(o) /home/dorkhome* 750 root.buggy --- r-x(g) --- --- r-x(g) /home/dorkhome/dork* 700 dork.buggy --- rwx --- rwx rwx or / 755 root.wheel rwx r-x rwx r-x(g) r-x(o) /home* 755 root.wheel r-x(g) r-x(o) r-x(g) r-x(g) r-x(o) /home/dorkhome* 750 root.buggy --- r-x(g) --- --- r-x(g) /home/dorkhome/dork* 700 dork.buggy --- rwx(o) --- rwx rwx depending on whether /home or /home/dorkhome is the mount point. Immediate conclusion: any "---" field in the right three columns represents a login failure related to the homedir. In the case of a local filesystem, "dork" cannot cd to HOME because user dork does not have r-x from / to HOME. This is because login2.2.7 does a seteuid(dork) before calling chdir, but does not setegid(buggy); so the chdir is done as dork.wheel, which fails. A setegid(buggy) fixes 2.2.7login. dork, once logged in and a member of group buggy, can cd to his HOME in all cases. This could be the basis of a truly horrid workaround involving /.profile /.cshrc /.bash_profile /.login. Adding a call to setegid(pwd->pw.gid) immediately before the seteuid that precedes the (only) chdir(2) call in login.c, we see improvements. In the local case, login is uneventful (except as noted later). In the NFS case, the situation is the same (pseudo-fixed). USING LOGIN 2.2.6: *) the local directory case succeeds. *) the NFS case now fails, for the obvious reason that "root" is really nobody.nobody when it comes time to read /home/dorkhome. dork is logged in, but he is set to "/". He can cd to his home, though, after login. This is the bug that 2.2.7 tried to solve with a seteuid(), but came close. The permissions on the directory tree exhibited here exercise a failure due to false group membership. Access through group membership was overlooked. It must have been assumed that there would be at least --x "other" permissions through the path. A RELATED PROBLEM: Throughout these exercises, intermittent messages appear in syslog, namely: Aug 8 10:15:08 castor login: _secure_path: cannot stat /home/dorkhome/dork/.login_conf: Permission denied These issue between "login:" and "Passwd:"; they arise from routine _secure_path, found in libutil. Casual examination of _secure_path() shows that it, too, may not be finding its way to dork's HOME in the intuitive way. DISCUSSION/REMEDIES: The question is whether this is a bug or a feature in 2.2.7. It's a feature: Then a doc. change should be made specifying that a user needs r-x access to his homedir either through the owner or other fields from / down to homedir. Drawback: this is bizarre semantics. What's the group field for? It's a bug: Then a fix of the nature suggested (setegid()) is in order. Drawback: making it a feature would require (particularly? only?) in the NFS case, for all users (including possibly root) to be members of group "buggy". This would break existing installations, including mine. I use the method where each user belongs to a unique group. Well, I leave it at that... Something(s) need to be changed. Or Mr. Snow needs to be told that his setup is in error. (It will fail under 2.2.6 with a maproot=nobody NFS mount anywhere in the path / --> HOME, I think). How I'd fix it: I guess the setegid(primary group of user) is the proper approach. This has implications for the ownership of the exported NFS fs in the NFS case-- the server must know about groups on clients, and these must be coordinated, NIS-ish, perhaps. Shudder. In 2.2.6, there's no problem with local dirs. Overall, Mr Snow is trying to achieve a goal here with permissions on homedirs and their parent dirs, which he hasn't explicitly stated. There may be a different approach to solve this problem. Possible reasons: *) Users should not be aware of other users' usernames. This is impossible on Unix, since /etc/passwd must be world-readable. *) Users should not be aware of other users' homedirs. Impossible, same reason. *) Users should not be aware of other users' group memberships. Impossible, /etc/group must be world-readable. *) Users should, by default, be unable to read or ls the tree under another user's homedir. This can be achieved by setting the permission on the homedir to 700. Then, for the local dir case, permissions on /home/dorkhome can be relaxed to r-w for "other". This fixes the nfs problems, I think. Blurry vision is setting in... I'm getting a headache... Dave -- "Today, machines sit on our desks and spend the overwhelming majority of their cycles doing nothing more important than blinking a cursor." --William Dickens http://www.feedmag.com/html/feedline/98.07dickens/98.07dickens_master.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message