Understood :-) Ques: At the end of the day when we reboot, and the machine comes back up, its basically running a whole bunch of scripts and commands. So isnt there some command(s) that I can manually run without doing an actual reboot, to achieve what the reboot would otherwise do ? Lets just say I cant afford to do a reboot, due to downtime/availability restrictions. I have a certain collection of policies on a machine. I need to be able to replace policy with a new set of policies with minimal downtime. Hence, I cant afford a reboot. Is there any way whatsoever I can run commands/scripts manually to avoid the reboot ? By the way, what file should I play with to control what context a user gets when login at the console VS the context a user should get after ssh-ing in ? Thanks as always. -----Original Message----- From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx] Sent: Tuesday, February 05, 2008 7:02 AM To: Hasan Rezaul-CHR010 Cc: Dave Quigley; SE Linux Subject: RE: Accurately setting Security Context of a user when ssh-ing in On Mon, 2008-02-04 at 19:44 -0500, Hasan Rezaul-CHR010 wrote: > Hi Dave, > > I forgot to mention that, after doing the un-tarring of the policy > collection, I did run the restorecon command: > > restorecon -rF / > restorecon -rF /etc/ > > And I did try running /usr/sbin/load_policy > > ... If I ssh in as Admin, I still get the wrong user context of > staff_u:sysadm_r:sysadm_t:s0 :-( > > But if I reboot the machine, and then ssh in as Admin, I get the correct > user context of staff_u:staff_r:staff_t !! > > Is there any other hidden thing that the reboot does that helps in > setting the user contexts correctly ? > > Thanks again for all the help... The logic for computing the login context for users is based on the context of the caller (e.g. the context in which the login process runs) as well as the authorized contexts for the user. For example, policy might allow a user to login at the console (local_login_t) as sysadm_r while preventing him from logging in directly into sysadm_r when logging in via ssh (sshd_t). Thus, if you merely untar the directory, reload policy, and relabel, your existing processes may still be running in the wrong contexts, and this can affect the context computed for login. A reboot ensures that everything transitions properly as defined by policy. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.