From: harrytaurus2002@hotmail.com (HarryCiao) Date: Mon, 14 Feb 2011 04:37:13 +0000 Subject: [refpolicy] Make crond able to use pam_namespace.so In-Reply-To: <20110213121032.GA2226@localhost.localdomain> References: , <20110213121032.GA2226@localhost.localdomain> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dom, Yep, we have been in the same situation here! xdm_t, sshd_t, local_login_t etc are all entrypoint domains and could establish login sessions. The problem is that the instance member directory created by one kind of entrypoint application can not be shared with another. I guess in your case the instantiated home directory created by sshd_t is different than the one created by gnome(in different namespace), that's why the pki can't be shared. I am wondering if using the "unmnt_remnt" option for pam_namespace.so in sshd PAM files could ever help your case, the sshd should unbind any member directory from the poly dir and then bind it on its own, so that no matter if gnome is started or not sshd would always save and then find the pki in the same one instantiated member home directory. While my problem really is to make crond_t reuse any existing instantiated home directory created by other entrypoint applications such as sshd_t or local_login_t. Best regards, Harry Date: Sun, 13 Feb 2011 13:10:58 +0100 From: domg472@gmail.com To: refpolicy at oss1.tresys.com Subject: Re: [refpolicy] Make crond able to use pam_namespace.so On Sun, Feb 13, 2011 at 10:46:32AM +0000, HarryCiao wrote: > > > > > Hello Chris and Dom, > > Please hold on this patch. I am now puzzled at if we should have crond use pam_namespace.so at all. > > The problem I run into is that the cron job process does not share the same namespace with the cron job submitter's process. > > If a staff user(mapped to staff_u) specifies cron job to write into a "/home/staff/somefile", if $HOME is polyinstantiated, then the cron job process will attempt to write into somefile to the BASE directory of /home/staff, rather than the MEMBER directory of /home/home.inst/staff_xxx created by ssh or login, resulting that this somefile is invisible to the staff user, only the root user could see it in the original base directory of /home/staff. > > How could I have the cron job process share the same namespace with the user's login session? > > Would below plan ever work? > 1. when crontab command creates user's cron job files in /var/spool/cron, the file name not only contains user's Linux User name, but also the submitter's role and MLS level; > > 2. crond determines cron job process security context from the name of above cron job files, rather than by get_default_context_with_level(). The cron job process will be in the same security context as the relevant submitter, rather than cronjob_t fetched from system_r:crond_t:s0 related entries in contexts/default_contexts or users/[user]. > > 3. crond PAM configs uses pam_namespace.so, which will find the cron job submitter's polyinstantiation member directory already created by ssh or login in the polyinstantiation parent directory. I am not sure but i use to have similar issues which in the end were never resolved. https://bugzilla.redhat.com/show_bug.cgi?id=519232 > > > Thanks, > Harry > > From: harrytaurus2002 at hotmail.com > To: cpebenito at tresys.com; refpolicy at oss1.tresys.com > Date: Fri, 11 Feb 2011 08:54:29 +0000 > Subject: [refpolicy] Make crond able to use pam_namespace.so > > > > > > > > > Hi Chirs, > > Another patch for crond_t, call the files_polyinstantiate_all() interface for it as what has been done for other entrypoint applications' domains, so that crond could work well when pam_namespace.so is used in its PAM config files and polyinstantiation is enabled. > > Thanks, > > Best regards, > Harry > > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110214/0ecf0a4f/attachment.html