From: dwalsh@redhat.com (Daniel J Walsh) Date: Mon, 14 Feb 2011 10:27:26 -0500 Subject: [refpolicy] Make crond able to use pam_namespace.so In-Reply-To: References: , <20110213121032.GA2226@localhost.localdomain> Message-ID: <4D5949DE.7010302@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/13/2011 11:37 PM, HarryCiao wrote: > 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 loc al_login_t. > > Best regards, > Harry > > > Date: Sun, 13 Feb 2011 13:10:58 +0100 > From: domg472 at 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 > > > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy I think this discussion should take place on the selinux list instead of the refpolicy list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZSdwACgkQrlYvE4MpobOp1wCfb/Kp/KYcGWRUU8h/xmp6W6bf 60IAoOrZov7CkQPlELmTIOCn7cfwLpii =SvEK -----END PGP SIGNATURE-----