su /sudo question

[Red Squirrel]

How can I setup bash so that if I do su user1 I will actually be logged as that user? So if I try to access folders, it will be under that user's permissions. It works if I do su - to go as root, but what if I want to go as another user? When I try, it still tries to use the permissions of the original user. So I SSH in as sshuser and go su ryan but it still tries to use sshuser's permissions if I try to write in a folder owned by ryan, for example.

 

[Nothinman]

'su user' works just like you want it to and 'su - user' will give you that full user's environment.

 

[pravi333]

also if you dont want to be prompted for that users password every time you su then you can change that using 'visudo' & 'NOPASSWD" option

 

[Nothinman]

also if you dont want to be prompted for that users password every time you su then you can change that using 'visudo' & 'NOPASSWD" option

sudo will always prompt for your password, no one else's and I believe it can only be used to run commands as root and not other users.

 

[Red Squirrel]

could it be that it works differently with ssh? since wether I do su - user or su user I still remain logged in as the previous user. If I do whoami it shows the original user. If I su as root then I'm fine, but can't seem to su as regular users for some reason.

 

[pravi333]

Originally posted by: RedSquirrel
could it be that it works differently with ssh? since wether I do su - user or su user I still remain logged in as the previous user. If I do whoami it shows the original user. If I su as root then I'm fine, but can't seem to su as regular users for some reason.

you tried 'sudo su - <user>'?

 

[Nothinman]

could it be that it works differently with ssh? since wether I do su - user or su user I still remain logged in as the previous user. If I do whoami it shows the original user. If I su as root then I'm fine, but can't seem to su as regular users for some reason.

No, su has no idea how you're logged in.

 

[Red Squirrel]

Yep

-bash-3.1$ su - ryan
Password:
-bash-3.1$ whoami
sshlogon
-bash-3.1$
-bash-3.1$ mkdir test
-bash-3.1$ dir -ls
total 24
4 -rw-r--r-- 1 sshlogon 1024   43 May  9 01:34 htpasswd.txt
8 drwxr-xr-x 3 sshlogon root 4096 Jul  1  2006 mail
4 drwxr-xr-x 2 sshlogon 1024 4096 Aug  7 16:45 test
8 drwxr-xr-x 4 sshlogon root 4096 Feb  5  2007 tmptransfers
-bash-3.1$

Even after the su I inherit the permissions of the original user (sshlogon in this case).

 

[Nothinman]

Works fine here.

me@box:/tmp$ id
uid=1000(me) gid=1000(me) groups=6(disk),20(dialout),24(cdrom),25(floppy),29(audio),40(src),44(video),46(plugdev),50(staff),108(powerdev),1000(me)
me@box:/tmp$ su - test
Password:
No directory, logging in with HOME=/
test@box:/$ id
uid=1001(test) gid=1001(test) groups=1001(test)
test@box:/$ cd /tmp
test@box:/tmp$ touch blah
test@box:/tmp$ ls -l blah
-rw-r--r-- 1 test test 0 2007-08-07 18:37 blah

 

[cleverhandle]

Originally posted by: RedSquirrel
-bash-3.1$ su - ryan
Password:
-bash-3.1$ whoami
sshlogon
-bash-3.1$
-bash-3.1$ mkdir test
-bash-3.1$ dir -ls
total 24
4 -rw-r--r-- 1 sshlogon 1024 43 May 9 01:34 htpasswd.txt
8 drwxr-xr-x 3 sshlogon root 4096 Jul 1 2006 mail
4 drwxr-xr-x 2 sshlogon 1024 4096 Aug 7 16:45 test
8 drwxr-xr-x 4 sshlogon root 4096 Feb 5 2007 tmptransfers
-bash-3.1$

Even after the su I inherit the permissions of the original user (sshlogon in this case).

There's more going on here than you're telling us. The file you're touching is getting created with gid 1024, which apparently is unknown to the local system. That really shouldn't happen unless you're messing with PAM or NSS in some way, or maybe manually editing /etc/passwd. Please describe exactly what your authentication system looks like. Also, check that the directory you show above isn't set sticky. That is, from the above prompt do "cd .. && ls -l" and see if the directory has an "s" in the permissions string.

 

[Red Squirrel]

hmm nope, no s anywhere. The box is a domain controller, if it matters. But not using anything fancy like pam or ldap, just default /etc/passwd authentication, domain authentication is done with wherever the smbpasswd is kept.

 

[cleverhandle]

Originally posted by: RedSquirrel
The box is a domain controller, if it matters.

It shouldn't, provided everything is set up to use standard unix authentication.

But not using anything fancy like pam or ldap, just default /etc/passwd authentication...

I just don't see how that's possible. su simply doesn't do what you're saying (and showing) it does without some serious modifications, most likely to PAM. I don't know how else to say it. Are you the only person admin'ing this box? Could anyone else have messed with the authentication settings?

In any event, let's follow what we've seen so far. What do you get from the following commands?

grep ryan /etc/passwd
grep sshlogon /etc/passwd
grep 1024 /etc/group
grep ryan /etc/group
grep sshlogon /etc/group

edit: BTW, what distribution is this?

 

[n0cmonkey]

Originally posted by: Nothinman
sudo will always prompt for your password, no one else's and I believe it can only be used to run commands as root and not other users.

From the man page:

-u The -u (user) option causes sudo to run the specified command as a
user other than root. To specify a uid instead of a username, use
#uid. Note that if the targetpw Defaults option is set (see
sudoers(5)) it is not possible to run commands with a uid not
listed in the password database.

 

[Nothinman]

Interesting, I guess sudo means "switch user do" instead of "super user do" like most people say =)

 

[Red Squirrel]

Originally posted by: cleverhandle

Originally posted by: RedSquirrel
The box is a domain controller, if it matters.

It shouldn't, provided everything is set up to use standard unix authentication.

But not using anything fancy like pam or ldap, just default /etc/passwd authentication...

I just don't see how that's possible. su simply doesn't do what you're saying (and showing) it does without some serious modifications, most likely to PAM. I don't know how else to say it. Are you the only person admin'ing this box? Could anyone else have messed with the authentication settings?

In any event, let's follow what we've seen so far. What do you get from the following commands?

grep ryan /etc/passwd
grep sshlogon /etc/passwd
grep 1024 /etc/group
grep ryan /etc/group
grep sshlogon /etc/group

edit: BTW, what distribution is this?

This is the output (as root)

[root@borg ~]# grep ryan /etc/passwd
ryan:x:1000:500:Ryan Auclair,,,:/home/ryan:/bin/false
email_ryan:x:1003:1003:,,,:/home/email_ryan:/bin/false
[root@borg ~]# grep sshlogon /etc/passwd
sshlogon:x:1024:1024:,,,:/home/sshlogon:/bin/bash
[root@borg ~]# grep 1024 /etc/group
[root@borg ~]# grep ryan /etc/group
[root@borg ~]# grep sshlogon /etc/group
[root@borg ~]# grep smbusers /etc/group
smbusers:x:500:auclair,p2puser,test



Theres no ryan group as that user is under smbusers, is that what could be causing the issue?

And I'm the only one admining this box, nobody else has any access.

If that group 1024 does not exist anywhere, I'm guessing something may be corrupted.

 

[cleverhandle]

Man, how did you end up with this?

Originally posted by: RedSquirrel
[root@borg ~]# grep ryan /etc/passwd
ryan:x:1000:500:Ryan Auclair,,,:/home/ryan:/bin/false

User "ryan" has his shell set to /bin/false. So when you were su'ing before, you weren't actually changing user, because /bin/false was dumping you right back out. Change /bin/false to /bin/bash and your immediate problems should be solved.

[root@borg ~]# grep sshlogon /etc/passwd
sshlogon:x:1024:1024:,,,:/home/sshlogon:/bin/bash
[root@borg ~]# grep 1024 /etc/group

There's still something wrong here. User "sshlogon" has its primary group set to 1024, but there's no entry for 1024 in /etc/group. Perhaps you created the account (which usually automatically creates the group) and then removed the group afterwards because you thought you didn't need it. Either recreate a group at gid 1024 or change sshlogon's primary gid to some group that actually exists.

If that group 1024 does not exist anywhere, I'm guessing something may be corrupted.

See notes above. This didn't happen randomly. Read the man pages for passwd and group before you mess around with account settings.

 

[Red Squirrel]

Adding shell to /bin/bash seems to have fixed it. Or should it be /bin/sh? Think I had originally set most shells to false to every user but root and sshlogon and I just forgot about that now that I want the user ryan to have shell access. These files were originally imported from my previous server when I had done a reformat for an upgrade so the group info probably got messed in that process.