Bug #1467
closedPerm problems after a 2.2.1 -> HEAD transition
0%
Description
Salute.
I did a fresh/clean install of a 2.2.1 dfly release and none of the problems I'm
going to describe were present. I, then, did a git pull to get the latest
sources from master, built kernel/world, installed kernel/world, did a make
upgrade and rebooted. And:
- I was unable to start X as normal user. The script kept dieing with:
'Cannot move /var/log/Xorg.0.log to /var/log/Xorg.0.log'. The Xorg binary
had the right ownership:group and its suid bit was set. I was able to run X
as root.
- chsh failed when invoked as a normal user, with this:
chsh: pw_tmp(): Permission denied. My /usr/bin/chsh has the right
owenership:group and its suid bit was set. I was able to use chsh as root.
- passwd failed when invoked as a normal user, with this:
passwd: pam_chauthtok(): error in service module
passwd: in pam_sm_chauthok(): pw_tmp() failed
My /usr/bin/passwd has the right owenership:group and its suid bit was set.
I was able to use passwd as root.
ktrace'ing chsh or passwd with and without -i doesn't return anything relevant
at all. The last lines are:
ktrace CALL execve(addr, addr, addr)
ktrace NAMI "/usr/bin/passwd"
ktrace NAMI "/usr/libexec/ld-elf.so.2"
Best regards,
Stathis
Updated by Anonymous about 15 years ago
pw_tmp() is supposed to create and open a temp file for editing the password
data, and copy the master password file into it. My /tmp is mounted with normal
permissions and honestly I haven't been convinced that this problem is related
to pw_tmp() directly. For instance Xorg's failure doesn't involve it.
Cheers,
Stathis
Updated by dillon about 15 years ago
:Stathis Kamperis <ekamperi@gmail.com> added the comment:
:
:pw_tmp() is supposed to create and open a temp file for editing the passwor=
:d
:data, and copy the master password file into it. My /tmp is mounted with no=
:rmal
:permissions and honestly I haven't been convinced that this problem is rela=
:ted
:to pw_tmp() directly. For instance Xorg's failure doesn't involve it.
:
:Cheers,
:Stathis
I have the same issue w/ e.g. chsh. It is probably related to the
recent vop_helper*() changes. I'll track it down.
-Matt
Updated by dillon about 15 years ago
Fix committed. UFS and other filesystems (but not HAMMER) were
using VOP_ACCESS() to check perms on open/create/rename/unlink. These
functions are not supposed to use the ruid/rgid. I created a
VOP_EACCESS() macro which passes the appropriate flag.
-Matt