Date: Sat, 8 Aug 1998 12:47:52 -0400 (EDT) From: djv@bedford.net To: dwhite@resnet.uoregon.edu (Doug White) Cc: djv@bedford.net, sno@teardrop.org, freebsd-questions@FreeBSD.ORG Subject: Re: Weird /home problem resolved [MAYBE] (LONG) Message-ID: <199808081647.MAA00998@lucy.bedford.net> In-Reply-To: <Pine.BSF.4.00.9808071346590.15104-100000@resnet.uoregon.edu> from Doug White at "Aug 7, 98 01:47:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808081647.MAA00998>