Bug #1467

Perm problems after a 2.2.1 -> HEAD transition

Added by Beket over 4 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by Beket over 4 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

#2 Updated by dillon over 4 years ago

:Stathis Kamperis <> 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

#3 Updated by dillon over 4 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

Also available in: Atom PDF