su problem: (/etc/group is ok) i rtfm... twice

[rew]

ok, i still have a problem with su. i have read the docs, infact, i have read them twice to make sure i didnt miss anything. i get the error:

[pjp]

If you log in as root, can you su to a user?

EDIT: Permissions are now covered in the FAQ Forum.
_________________
Quis separabit? Quo animo?

[squanto]

At a prompt for your normal user, type "groups", the output should be something like this:

users disk wheel floppy audio cdrom video cdrw

Then you can tell if you are in wheel. Make sure when adding yourself to groups that you include all other groups you are currenlty in so that you retain your status as being apart of those groups as well.

Andrew

[travis]

I had this very same problem. So frustrating! So I eventually re-emerged pam (I think) and su started working again.

Good luck.

[rew]

reply #1: yes, i can su from root to a 'normal' user

reply #2: when i run groups my output is: users wheel audio

im going to try to remerge pam to see if that helps now.
=> update, re-emergin pam had no effect

[rew]

i just re-emreged pam and i still am having the original problem

[rac]

Is there anything interesting in /var/log/auth.log?
_________________
For every higher wall, there is a taller ladder

[rew]

i dont even have a file at /var/log/auth.log

also, i just found that when trying to run `ps` as a regular user i get this error: "This /bin/ps is not secure for setuid operation."

[rac]

What system logger are you using? Can you emerge strace if you haven't already and post the output of

[rew]

[root /home/media]$ strace -u rew ps
execve("/bin/ps", ["ps"], [/* 42 vars */]) = 0
brk(0) = 0x8163588
fcntl64(0, F_GETFD) = 0
fcntl64(1, F_GETFD) = 0
fcntl64(2, F_GETFD) = 0
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=76143, ...}) = 0
old_mmap(NULL, 76143, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3) = 0
open("/lib/libproc.so.2.0.7", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000#\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0555, st_size=45611, ...}) = 0
old_mmap(NULL, 49288, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002a000
mprotect(0x40033000, 12424, PROT_NONE) = 0
old_mmap(0x40033000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8000) = 0x40033000
old_mmap(0x40034000, 8328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40034000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\250\224"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1425012, ...}) = 0
old_mmap(NULL, 1241088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40037000
mprotect(0x4015c000, 40960, PROT_NONE) = 0
old_mmap(0x4015c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x124000) = 0x4015c000
old_mmap(0x40162000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40162000
close(3) = 0
munmap(0x40017000, 76143) = 0
uname({sys="Linux", node="luna.daspek.com", ...}) = 0
open("/proc/uptime", O_RDONLY) = 3
lseek(3, 0, SEEK_SET) = 0
read(3, "3962.00 3780.76\n", 1023) = 16
open("/proc/stat", O_RDONLY) = 4
lseek(4, 0, SEEK_SET) = 0
read(4, "cpu 28031 0 7626 756743\ncpu0 14"..., 1023) = 685
lseek(3, 0, SEEK_SET) = 0
read(3, "3962.00 3780.76\n", 1023) = 16
getuid32() = 1000
geteuid32() = 0
write(2, "This /bin/ps is not secure for s"..., 49This /bin/ps is not secure for setuid operation.
) = 49
_exit(1)

[Houdini]

I suspect some of the security options in the kernel (GRSecurity, right?) went awry. Try rebuilding a kernel with all that turned off. If it works, start turning things on one by one. I know, it sounds like a lot of work, but it might fix the system.
_________________
^]:wq

[rac]

OK, one other thing I should have asked first. Is /bin/ps setuid? If so, do you know why? Could you try

[rew]

rac: that worked, but i dont care about that as much as I care about getting su to work :-) still have the original problem
------------------------------------
the other dude: sorry, no security settings in the kernel

[rac]

[rew]

returns of `emerge -s .*log.*` show I have:
metalog (0.6-r10)
pam-login (3.6-r2)

also~
`cat /var/log/critical/current` shows:
Aug 24 22:02:49 [login(pam_unix)] check pass; user unknown
Aug 24 22:04:47 [login(pam_unix)] service(login) ignoring max retries; 4 > 3
which is not exactly the right date but so far, that is the best login type file i can do for ya right now

lastly~
`cat /etc/pam.d/su`

[rac]

How long have you had this installation running? Did su suddenly stop working? Has it ever worked on this installation? What network daemons are you running? Are you using NIS? Have you noticed anything else unusual about this computer lately?
_________________
For every higher wall, there is a taller ladder

[pjp]

I haven't heard mention of the /etc/suauth file. What do you have in it?
_________________
Quis separabit? Quo animo?

[ebrostig]

One thing that nobody have asked you, is what is the permission for your /bin/su program?
Mine is : -rwsr-xr-x.
If I change this to -rwxr-xr-x I get the following error when I try to su another user:
Password:
su: Authentication failure
Sorry.


Hope this helps!

[blasterboy]

Did you edit the group file manually by any chance ? I did and gave me the same problems...

As root, I edited the group file manually, and added my user to wheel group. This gave me the correct response when typing groups command that I was in the wheel group, but didn't let me su from that user to root.

It does work when I used the usermod command as given here in the forums somewhere :
usermod -G users,wheel user

My guess is that usermod does more than just edit the group file...

BB

[ebrostig]

[rew]

IT works, thanks ebrostig, i just did a chmod a+s /bin/su and it seems to be working now. should i change it so only some have s or is it ok the way it is? (ps, thanks to everyone for their help)
_________________
linux-2.4.20 i686 SMP
Tyan Tiger MP
Dual Athlon MP 1600+
512MB EEC (1/4)
PNY Verto 64MB - GeForce4 MX 420
'Cheep-ass NIC, CDRW & DVD'

[ebrostig]

[barnie]

How is this "must be wheel" realized?

I do not have Gentoo - I'm currently only planning to have it soon, so I cannot look.

If su is owned by root.root and has u+s and o+x rights as you have posted before, then _everyone_ will suid to root and there will not be a must to be in wheel.

I think this should look like this:

-rwsr-xr-- su root wheel

to work as expected - not:

-rwsr-xr-x su root root

Or am I wrong?

[cchee]

I normally use sudo if i need "root" command for user. This is better alternative than just add them to "root user" group imho. If the user really really need full blow. he/she will still have to go thru sudo, i.e. sudo su -
with user password prompt so you can do some basic sysadmin security tracking of some sort combine with tripwire.

[claw]

If you have sys-apps/shadow 4.0.4.1-r3, then more than "su" is broken. See Gentoo Bug 56129.

The fix is to "chmod u+s" all the files listed in that bug report.