Project

General

Profile

Actions
Copy link

Bug #1467

closed

Perm problems after a 2.2.1 -> HEAD transition

Added by Anonymous over 15 years ago. Updated over 15 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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

Actions
Copy link
 #1

Updated by Anonymous over 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

Actions
Copy link
 #2

Updated by dillon over 15 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
Actions
Copy link
 #3

Updated by dillon over 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
Actions
Copy link

Also available in: Atom PDF