>>>>> On Mon, 01 Apr 2002 10:35:35 -0500, Jon McCain >>>>> <[EMAIL PROTECTED]> was runoured to have said:
> All of this has gotten me to thinking about another flaw in the way I > have things set up. I'm preventing users from getting to a $ by running > a menu from their profile. > exec /usr/bin/menu > This works fine since the exec causes menu to become their shell > process. > But some smart user could get around this by using pscp to upload their > own .bash_profile. Even if I fix it so I have them chroot'd on their > home would not prevent this since this file is in their home. Their shell will already be chrooted by the time .bash_profile is run, so I don't see the problem here... Unless you don't want to give them a shell at all, for some reason? > But changing permissions on the .bash_profile so they don't own it (and > not in their group) should take care of that problem. They can read it > all they want, just not change it. But they can remove and replace it with something else, since they own the parent dir. You'd have to turn on the sticky bit of their home dir and take away the ownership, e.g. ownership root.<user's group> and permissions 1770. This way they get a nice EPERM if they try to mess with anything they don't own in their home directory. Rgds, /-sb. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
