I want to prevent some users from running su, but not others. I've tried editing my sudoers file, so now, said users can't do
% sudo su

but just
% su

still works.

Any thoughts would be appreciated.

Thanks

umm, can't you just chmod su so only root can execute it?

I suppose that would be a simple fix. I'll give it a shot. I'll guess then I'll just have to
% sudo su

Thanks

I was about to do what you suggested when I noticed the following:
My question is how do I do this and keep the s-flag (which I assume means secure, or such)?

Look in your /etc/pam.d for a file called "su". Now read up on the pam_listfile module.

s means the command is suid/gid
see the manpage...but since you want others to execute, you still probably want it.

unSpawn is right though, if Pam can control that, go and use that (assuming you have Pam...)

hehe I'm going to tell you another way to do it even though I am at risk of getting stoned to death for it. This is 'old-school' and most people have a problem with it.

What you do is create a group, usually called 'wheel', and add all the users you want to have access to the su command to the wheel group. Then chgrp su to the wheel group and chmod su so that only the owner and group have execute privelages.

Thanks all, these all seem like good solutions. I was able to correctly chmod su, but it kinda opened a bigger whole, because now, I can just do sudo su without having to enter any password at all. I'll try messing around with pam.d/su

Thanks

its not 'old school'. Its the terrible, terrible way.

sudo has eliminated the need for a wheel group, and I still am to hear of a good argument for it.

btw, how does your suggestion differ from my 'sudo + chmod' suggestion (except for the fact that it uses sudo instad of a wheel group)?

Not to get too far off topic, but I don't really see what's so bad about a wheel group.

Admins get a certain amount of privilege that users don't. It's the way it works. Although I've only been on university networks mostly. It keeps a few bad apples from destroying the network and preventing other students from doing work. And I don't really need to be running most of those commands myself, anyway.

Then there's the argument of too many cooks in the kitchen...

Anyhoo, later.

I was simply just throwing another option out there for Itzac. If you are going to say that the technique I suggested is 'the terrible, terrible way' then you should tell us why you think it is so terrible. Not that I disagree with you but I'd like to here your thoughts on why it is so inferior to sudo.

<OT>
here's basically my problem with a wheel group:
there is an assumption that some people just need more power than others, and therefore get special privileges. The easiest example cited is a network admin. Now, I understand that people (except for root) may need some permissions that most can't.

The difference is sort of subtle. Wheel has some set of commands, etc. and allows everyone in the group to use them. With sudo, you can be more specific. The webmaster may need access to apache, etc. but has no need for backups, etc. While someone may be designated for software, backups - but really have no need for something else. Heck, you can have someone that is only responsible for booting, shutting down, etc. So sudo allows you to specify 'groups' - webmaster, backups, janitor - without worrying that the janitor will accidently screw with the cronjobs for backups, or redesign the webpage. Now, this is a very simplistic model, but hopefully you can spot the difference. Wheel assumes some people just need a bunch of permissions, sudo gives you everything you need to get the job done, and no more.

Hopefully this also answers Crashed_Again. True its a technique. But in my OPINION, its like running su, or just running everything as root - they're both techniques, right?
; )

cheers

I guess what it comes down to then is that these are two means to one end. Sudo is just far more precise and refined than Wheel's rock-on-a-stick approach.

All's working reasonably well, now, btw.

Thanks,