Date: Wed, 5 Aug 1998 16:13:36 -0500 (CDT) From: Guy Helmer <ghelmer@scl.ameslab.gov> To: James Snow <sno@teardrop.org> Cc: djv@bedford.net, freebsd-questions@FreeBSD.ORG Subject: Re: Weird /home problem Message-ID: <Pine.SGI.3.96.980805155553.22923M-100000@demios.scl.ameslab.gov> In-Reply-To: <Pine.BSF.3.96.980805125333.29493F-100000@silver.teardrop.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Aug 1998, James Snow wrote: > [...] Here is exactly what I did. I would be really interested to know > if this did not produce the same problem for other people. > > Created a new group entry, buggy - /etc/group: (dork being the user to be > added) > > buggy:*:5000:dork > > Run vipw and put the enter the following line: > > dork::1005:5000:Dork:/home/buggy/dork:/usr/local/bin/tcsh > > Verify that /home is 755 - chmod 755 /home > Make the sub of home - mkdir /home/buggy > Set its perms - chown root:buggy /home/buggy ; chmod 750 /home/buggy > Then the user - > mkdir /home/buggy/dork ; chown dork:buggy /home/buggy/dork > chmod 700 /home/buggy/dork > > Then when he logs in, he gets: > > No home directory. > Logging in with home = "/". > > and the logs get: > > login: _secure_path: cannot stat /home/buggy/dork/.login_conf: Permission > denied You've discovered an interesting case in login(1): it uses seteuid() when checking for the home directory and the .login_conf file but it doesn't modify its gid list, so it can't see past /home/buggy for lack of privilege at that point. > [...] > > The error message you're getting is consistent with logging > > in to a non-existent directory. > > But why does login behave differently when called at actual login and when > called from the command line immediately after the botched login? That is, > it doesn't find $home after logging in, but subsequently typing 'login' > and logging in again works perfectly. When called from the command line (assuming the user is logging in again as (him|her)self), the gid list is properly setup and login(1) can see into /home/buggy. It appears the user's security environment has to be used to find the per-user login capability file and then the security environment has to revert to root privileges to set the login capabilities and/or change the password if necessary. Could the existing setgid(2) & initgroups(3) calls simply be moved up ahead of the initial seteuid(2) call? Since the group list is not checked or modified before this point, it must not be a security risk at that point? Otherwise, I suppose you could do a getgroups(2), setegid(2), and initgroups(3) before the first existing seteuid(2), then after the second seteuid(2), use setegid(2) and setgroups(2) to return the group list to its original state. Guy Helmer Guy Helmer, Graduate Student, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SGI.3.96.980805155553.22923M-100000>