On Sun, Apr 11, 2004 at 03:46:16PM +1200, Andrew Tarr wrote:
> I think so. I'm not entirely sure about how to interpret the 'setuid'
> stuff in either numeric permissions or the output of 'ls -l', and I
> can neither seem to coerce ls into giving numeric permissions or
> immediately find anything that will relate the number to the 'ls'
> output in this case.
> [EMAIL PROTECTED]:~$ ls -l /bin/su
> -rwsr-xr-x 1 root root 23448 Mar 11 09:36 /bin/su
> that looks like 4755 to me, but that 4th letter is a bit of a mystery
> to me.
Yes, that's correct. If you're not sure, you can use stat(1):
$ stat /bin/su | grep 'Access'
Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
The fourth letter, 's', is the setuid bit--this is the '4' in '4755'.
This bit means that /bin/su will execute as the user the file is owned
by (in this case, root), rather than the user executing the file.
> > If you're logged in as root, does using su(1) to change to another
> > user work? If it's failing, strace(1) the su process and look of
> > obvious failures, or post the censored strace log to the list.
> Yes, that works.
Well, that proves that the PAM subsystem isn't totally broken
(operationally, at least... let's not go into the design of PAM).
The next step is to check your system logs. As somebody else suggested,
check /var/log/auth.log after you've attempted to su from your user to
root.
On other thing... I'm assuming that your root user doesn't have an
'empty' password.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
