permission problems w/ ordinary user ....
freebsd at edvax.de
Sun Aug 3 00:01:08 UTC 2014
On Sat, 02 Aug 2014 18:56:29 -0500, William A. Mahaffey III wrote:
> On 08/02/14 18:40, Polytropon wrote:
> > On Sat, 02 Aug 2014 18:28:47 -0500, William A. Mahaffey III wrote:
> >> .... I have been trying to setup the regular user (me, non-root) on my
> >> newly minted FreeBSD 9.3 box. I tried su-ing from tooy & ssh-ing in as
> >> me from another box, both give weird results, see the following from my
> >> syslog:
> >> [...]
> >> Aug 2 18:23:01 kabini1 sshd: _secure_path: cannot stat
> >> /home/wam/.login_conf: Permission denied
> >> also, the home-directory keeps getting the 'x' permission bit set to off
> >> by .... something ....
> > I think you have described the reason for the problem:
> > The x attribute for a directory means "enter and search"
> > and should be _set_ for the user. If it's not, the user
> > cannot enter his own home directory or access files
> > within it. In this case, /home/wam/.login_conf cannot
> > be read which seems to be neccessary for the login
> > process.
> > You need to find that "something" that created or altered
> > /home/wam with the x attribute off. Login as root and
> > correct the setting manually, so you should be able to
> > login afterwards.
> > This is how the resulting "ls -l /home" output it should
> > look like for your user:
> > drwx------ [...] wam wam [...] wam/
> > ^
> > (This is minimum permissions; drwxrwxr-x or drwxr-x---
> > are other common examples.)
> > How did you introduce the user to the system? Did you
> > use "adduser" or "pw add"?
> I used useradd as root, & the permissions were set correctly to begin
Okay, so a "problem upon initiation" does not occur.
> I suspect that the failed logins are triggering the reset, but w/
> little proof ....
This is _very_ strange. Do you have anything in your login
scripts, like ~/.cshrc (or ~/.tcshrc), ~/.login or ~/.profile
that looks "offending"?
> I have reset the perms as root several times during
> this exercise, & they keep getting unset after the login failure ....
I'm not sure what part of the system could trigger that behavuiour,
it just sounds totally wrong...
However, you could run truss on an login attempt to see what
the process does (invisibly), calling /bin/chmod via execve()
or by chmod() or popen().
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions