Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Saul Wold]

On 01/27/2011 03:38 AM, poky-bounces@yoctoproject.org wrote:
> From: Kevin Tian<kevin.tian@intel.com>
>
> several cron related test cases in LTP reveals that our current cron recipe
> is not complete:
>
> a) a complete cron hierarchy better have:
>       /etc/crontab
>       /etc/cron.d
>       /etc/cron.hourly
>       /etc/cron.daily
>       /etc/cron.weekly
>       /etc/cron.monthly
>
> b) for a normal user to use crontab command:
>       add a new group - crontab
>       /usr/bin/crontab is setgid to root:crontab
>       /var/spool/cron is owned by root:crontab
>
> below are optional, and thus not included in the default setup:
>       /etc/cron.deny
>       /etc/cron.allow
>
> cronie by default only allows root user to use crontab, if neither cron.deny
> nor cron.allow exists. They are controlled by final policy deployed on the
> product.
>
> Signed-off-by: Kevin Tian<kevin.tian@intel.com>
> ---
>   meta/recipes-extended/cronie/cronie/crontab  |   10 ++++++++
>   meta/recipes-extended/cronie/cronie_1.4.6.bb |   33 ++++++++++++++++++++++++-
>   2 files changed, 41 insertions(+), 2 deletions(-)
>   create mode 100644 meta/recipes-extended/cronie/cronie/crontab
>
> diff --git a/meta/recipes-extended/cronie/cronie/crontab b/meta/recipes-extended/cronie/cronie/crontab
> new file mode 100644
> index 0000000..cc9169e
> --- /dev/null
> +++ b/meta/recipes-extended/cronie/cronie/crontab
> @@ -0,0 +1,10 @@
> +# /etc/crontab: system-wide crontab
> +# Unlike any other crontab you don't have to run the `crontab'
> +# command to install the new version when you edit this file
> +# and files in /etc/cron.d. These files also have username fields,
> +# that none of the other crontabs do.
> +
> +SHELL=/bin/sh
> +PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
> +
> +# m h dom mon dow user	command
> diff --git a/meta/recipes-extended/cronie/cronie_1.4.6.bb b/meta/recipes-extended/cronie/cronie_1.4.6.bb
> index 6b4c64e..09714c7 100644
> --- a/meta/recipes-extended/cronie/cronie_1.4.6.bb
> +++ b/meta/recipes-extended/cronie/cronie_1.4.6.bb
> @@ -14,10 +14,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=963ea0772a2adbdcd607a9b2ec320c11 \
>
>   SECTION = "utils"
>
> -PR = "r0"
> +PR = "r1"
>
>   SRC_URI = "https://fedorahosted.org/releases/c/r/cronie/cronie-${PV}.tar.gz \
> -           file://crond.init"
> +           file://crond.init \
> +           file://crontab"
>
>   SRC_URI[md5sum] = "968e3d3e7c8e1d0588d533883482d3fa"
>   SRC_URI[sha256sum] = "4435484c28a4452ee37db27182675660cdebf16d8956771b28c8a6f2e9c8048b"
> @@ -32,4 +33,32 @@ do_install_append () {
>   	install -d ${D}${sysconfdir}/init.d/
>   	install -m 0644 ${S}/crond.sysconfig ${D}${sysconfdir}/sysconfig/crond
>   	install -m 0755 ${WORKDIR}/crond.init ${D}${sysconfdir}/init.d/crond
> +
> +	# below are necessary for a complete cron environment
> +	install -d ${D}${localstatedir}/spool/cron
> +	install -m 0755 ${WORKDIR}/crontab ${D}${sysconfdir}/
> +        mkdir -p ${D}${sysconfdir}/cron.d
> +	mkdir -p ${D}${sysconfdir}/cron.hourly
> +	mkdir -p ${D}${sysconfdir}/cron.daily
> +	mkdir -p ${D}${sysconfdir}/cron.weekly
> +	mkdir -p ${D}${sysconfdir}/cron.monthly
> +}
> +
> +pkg_postinst_${PN} () {
> +	if [ "x$D" != "x" ] ; then
> +		exit 1
> +	fi
> +
> +	# below setting is necessary to allow normal user using crontab
> +
> +	# add 'crontab' group and setgid for crontab binary
> +	grep crontab /etc/group || addgroup crontab
> +	chown root:crontab /usr/bin/crontab
> +	chmod 2755 /usr/bin/crontab
> +
> +	# allow 'crontab' group write to /var/spool/cron
> +	chown root:crontab /var/spool/cron
> +	chmod 770 /var/spool/cron
> +
> +	chmod 600 /etc/crontab
>   }
Kevin,

I am going to hold off pulling this and the at changes.

Is there a specific reason that you are creating this as a post install 
operation for the permission management, both this and the at recipes 
are doing this.  Please remember that adding additional items that run 
at first boot slow things down.

Is it possible to run these permission changes at actual install time, 
instead of on the target.

Thanks
   Sau!

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Tian, Kevin]

> From: Wold, Saul
> Sent: Friday, January 28, 2011 2:00 AM
> > +
> > +pkg_postinst_${PN} () {
> > +	if [ "x$D" != "x" ] ; then
> > +		exit 1
> > +	fi
> > +
> > +	# below setting is necessary to allow normal user using crontab
> > +
> > +	# add 'crontab' group and setgid for crontab binary
> > +	grep crontab /etc/group || addgroup crontab
> > +	chown root:crontab /usr/bin/crontab
> > +	chmod 2755 /usr/bin/crontab
> > +
> > +	# allow 'crontab' group write to /var/spool/cron
> > +	chown root:crontab /var/spool/cron
> > +	chmod 770 /var/spool/cron
> > +
> > +	chmod 600 /etc/crontab
> >   }
> Kevin,
> 
> I am going to hold off pulling this and the at changes.
> 
> Is there a specific reason that you are creating this as a post install
> operation for the permission management, both this and the at recipes
> are doing this.  Please remember that adding additional items that run
> at first boot slow things down.
> 
> Is it possible to run these permission changes at actual install time,
> instead of on the target.
> 

I thought about this when baking the patch, and finally went to this way because
there's chown operation and new group needs to be created. This has to be done
on the target, as you'll see in other similar recipes like dbus, hal, ...

Thanks
Kevin

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Saul Wold]

On 01/27/2011 04:07 PM, Tian, Kevin wrote:
>> From: Wold, Saul
>> Sent: Friday, January 28, 2011 2:00 AM
>>> +
>>> +pkg_postinst_${PN} () {
>>> +	if [ "x$D" != "x" ] ; then
>>> +		exit 1
>>> +	fi
>>> +
>>> +	# below setting is necessary to allow normal user using crontab
>>> +
>>> +	# add 'crontab' group and setgid for crontab binary
>>> +	grep crontab /etc/group || addgroup crontab
>>> +	chown root:crontab /usr/bin/crontab
>>> +	chmod 2755 /usr/bin/crontab
>>> +
>>> +	# allow 'crontab' group write to /var/spool/cron
>>> +	chown root:crontab /var/spool/cron
>>> +	chmod 770 /var/spool/cron
>>> +
>>> +	chmod 600 /etc/crontab
>>>    }
>> Kevin,
>>
>> I am going to hold off pulling this and the at changes.
>>
>> Is there a specific reason that you are creating this as a post install
>> operation for the permission management, both this and the at recipes
>> are doing this.  Please remember that adding additional items that run
>> at first boot slow things down.
>>
>> Is it possible to run these permission changes at actual install time,
>> instead of on the target.
>>
>
> I thought about this when baking the patch, and finally went to this way because
> there's chown operation and new group needs to be created. This has to be done
> on the target, as you'll see in other similar recipes like dbus, hal, ...
>
Since this is a similar theme, is there a bbclass or method that could 
be written in order to handle adding users/groups to the passwd/group 
file during sysroot creation time, prior to packaging?

Will pseudo handle this correctly?

Maybe for 1.0 we go this route, but we should think more about this, in 
order to create the users and groups we need.

I think Ke may run into this also for the rootless X work he is doing.

Sau!


> Thanks
> Kevin
>

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Yu Ke]

On Jan 27, 16:34, Saul Wold wrote:
> On 01/27/2011 04:07 PM, Tian, Kevin wrote:
> >>From: Wold, Saul
> >>Sent: Friday, January 28, 2011 2:00 AM
> >>>+
> >>>+pkg_postinst_${PN} () {
> >>>+	if [ "x$D" != "x" ] ; then
> >>>+		exit 1
> >>>+	fi
> >>>+
> >>>+	# below setting is necessary to allow normal user using crontab
> >>>+
> >>>+	# add 'crontab' group and setgid for crontab binary
> >>>+	grep crontab /etc/group || addgroup crontab
> >>>+	chown root:crontab /usr/bin/crontab
> >>>+	chmod 2755 /usr/bin/crontab
> >>>+
> >>>+	# allow 'crontab' group write to /var/spool/cron
> >>>+	chown root:crontab /var/spool/cron
> >>>+	chmod 770 /var/spool/cron
> >>>+
> >>>+	chmod 600 /etc/crontab
> >>>   }
> >>Kevin,
> >>
> >>I am going to hold off pulling this and the at changes.
> >>
> >>Is there a specific reason that you are creating this as a post install
> >>operation for the permission management, both this and the at recipes
> >>are doing this.  Please remember that adding additional items that run
> >>at first boot slow things down.
> >>
> >>Is it possible to run these permission changes at actual install time,
> >>instead of on the target.
> >>
> >
> >I thought about this when baking the patch, and finally went to this way because
> >there's chown operation and new group needs to be created. This has to be done
> >on the target, as you'll see in other similar recipes like dbus, hal, ...
> >
> Since this is a similar theme, is there a bbclass or method that
> could be written in order to handle adding users/groups to the
> passwd/group file during sysroot creation time, prior to packaging?
> 
> Will pseudo handle this correctly?
> 
> Maybe for 1.0 we go this route, but we should think more about this,
> in order to create the users and groups we need.
> 
> I think Ke may run into this also for the rootless X work he is doing.

Yes, rootless X also do similar things to create X user in post-inst. I will work with Kevin to see if it is possible to generialized it as one bbclass.

Regards
Ke

> 
> Sau!
> 
> 
> >Thanks
> >Kevin
> >
> 
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Tian, Kevin]

> From: Wold, Saul
> Sent: Friday, January 28, 2011 8:34 AM
> 
> On 01/27/2011 04:07 PM, Tian, Kevin wrote:
> >> From: Wold, Saul
> >> Sent: Friday, January 28, 2011 2:00 AM
> >>> +
> >>> +pkg_postinst_${PN} () {
> >>> +	if [ "x$D" != "x" ] ; then
> >>> +		exit 1
> >>> +	fi
> >>> +
> >>> +	# below setting is necessary to allow normal user using crontab
> >>> +
> >>> +	# add 'crontab' group and setgid for crontab binary
> >>> +	grep crontab /etc/group || addgroup crontab
> >>> +	chown root:crontab /usr/bin/crontab
> >>> +	chmod 2755 /usr/bin/crontab
> >>> +
> >>> +	# allow 'crontab' group write to /var/spool/cron
> >>> +	chown root:crontab /var/spool/cron
> >>> +	chmod 770 /var/spool/cron
> >>> +
> >>> +	chmod 600 /etc/crontab
> >>>    }
> >> Kevin,
> >>
> >> I am going to hold off pulling this and the at changes.
> >>
> >> Is there a specific reason that you are creating this as a post install
> >> operation for the permission management, both this and the at recipes
> >> are doing this.  Please remember that adding additional items that run
> >> at first boot slow things down.
> >>
> >> Is it possible to run these permission changes at actual install time,
> >> instead of on the target.
> >>
> >
> > I thought about this when baking the patch, and finally went to this way
> because
> > there's chown operation and new group needs to be created. This has to be
> done
> > on the target, as you'll see in other similar recipes like dbus, hal, ...
> >
> Since this is a similar theme, is there a bbclass or method that could
> be written in order to handle adding users/groups to the passwd/group
> file during sysroot creation time, prior to packaging?
> 
> Will pseudo handle this correctly?
> 
> Maybe for 1.0 we go this route, but we should think more about this, in
> order to create the users and groups we need.

Yes, we can think more about it. The less postinst works, the better.

But generally speaking, group/permission operations in my observation are 
quick in the 1st boot. There're other postinst being heavy. :-)

Thanks
Kevin

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Saul Wold]

On 01/27/2011 05:18 PM, Tian, Kevin wrote:
>> From: Wold, Saul
>> Sent: Friday, January 28, 2011 8:34 AM
>>
>> On 01/27/2011 04:07 PM, Tian, Kevin wrote:
>>>> From: Wold, Saul
>>>> Sent: Friday, January 28, 2011 2:00 AM
>>>>> +
>>>>> +pkg_postinst_${PN} () {
>>>>> +	if [ "x$D" != "x" ] ; then
>>>>> +		exit 1
>>>>> +	fi
>>>>> +
>>>>> +	# below setting is necessary to allow normal user using crontab
>>>>> +
>>>>> +	# add 'crontab' group and setgid for crontab binary
>>>>> +	grep crontab /etc/group || addgroup crontab
>>>>> +	chown root:crontab /usr/bin/crontab
>>>>> +	chmod 2755 /usr/bin/crontab
>>>>> +
>>>>> +	# allow 'crontab' group write to /var/spool/cron
>>>>> +	chown root:crontab /var/spool/cron
>>>>> +	chmod 770 /var/spool/cron
>>>>> +
>>>>> +	chmod 600 /etc/crontab
>>>>>     }
>>>> Kevin,
>>>>
>>>> I am going to hold off pulling this and the at changes.
>>>>
>>>> Is there a specific reason that you are creating this as a post install
>>>> operation for the permission management, both this and the at recipes
>>>> are doing this.  Please remember that adding additional items that run
>>>> at first boot slow things down.
>>>>
>>>> Is it possible to run these permission changes at actual install time,
>>>> instead of on the target.
>>>>
>>>
>>> I thought about this when baking the patch, and finally went to this way
>> because
>>> there's chown operation and new group needs to be created. This has to be
>> done
>>> on the target, as you'll see in other similar recipes like dbus, hal, ...
>>>
>> Since this is a similar theme, is there a bbclass or method that could
>> be written in order to handle adding users/groups to the passwd/group
>> file during sysroot creation time, prior to packaging?
>>
>> Will pseudo handle this correctly?
>>
>> Maybe for 1.0 we go this route, but we should think more about this, in
>> order to create the users and groups we need.
>
> Yes, we can think more about it. The less postinst works, the better.
>
> But generally speaking, group/permission operations in my observation are
> quick in the 1st boot. There're other postinst being heavy. :-)
>
The more you add to 1st boot that could be done during rootfs creation 
will always add more time, it's better to do it at rootfs time if possible.

Will you be-able to modify this for 1.0 M3?  If not will there be a plan 
for M4 or 1.1?

Sau!


> Thanks
> Kevin
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>

Re: [PATCH 2/5] cronie: enable multi-user crontab usage and make cron environment complete

[Tian, Kevin]

> From: Wold, Saul
> Sent: Tuesday, February 01, 2011 8:31 AM
> 
> On 01/27/2011 05:18 PM, Tian, Kevin wrote:
> >> From: Wold, Saul
> >> Sent: Friday, January 28, 2011 8:34 AM
> >>
> >> On 01/27/2011 04:07 PM, Tian, Kevin wrote:
> >>>> From: Wold, Saul
> >>>> Sent: Friday, January 28, 2011 2:00 AM
> >>>>> +
> >>>>> +pkg_postinst_${PN} () {
> >>>>> +	if [ "x$D" != "x" ] ; then
> >>>>> +		exit 1
> >>>>> +	fi
> >>>>> +
> >>>>> +	# below setting is necessary to allow normal user using crontab
> >>>>> +
> >>>>> +	# add 'crontab' group and setgid for crontab binary
> >>>>> +	grep crontab /etc/group || addgroup crontab
> >>>>> +	chown root:crontab /usr/bin/crontab
> >>>>> +	chmod 2755 /usr/bin/crontab
> >>>>> +
> >>>>> +	# allow 'crontab' group write to /var/spool/cron
> >>>>> +	chown root:crontab /var/spool/cron
> >>>>> +	chmod 770 /var/spool/cron
> >>>>> +
> >>>>> +	chmod 600 /etc/crontab
> >>>>>     }
> >>>> Kevin,
> >>>>
> >>>> I am going to hold off pulling this and the at changes.
> >>>>
> >>>> Is there a specific reason that you are creating this as a post install
> >>>> operation for the permission management, both this and the at recipes
> >>>> are doing this.  Please remember that adding additional items that run
> >>>> at first boot slow things down.
> >>>>
> >>>> Is it possible to run these permission changes at actual install time,
> >>>> instead of on the target.
> >>>>
> >>>
> >>> I thought about this when baking the patch, and finally went to this way
> >> because
> >>> there's chown operation and new group needs to be created. This has to
> be
> >> done
> >>> on the target, as you'll see in other similar recipes like dbus, hal, ...
> >>>
> >> Since this is a similar theme, is there a bbclass or method that could
> >> be written in order to handle adding users/groups to the passwd/group
> >> file during sysroot creation time, prior to packaging?
> >>
> >> Will pseudo handle this correctly?
> >>
> >> Maybe for 1.0 we go this route, but we should think more about this, in
> >> order to create the users and groups we need.
> >
> > Yes, we can think more about it. The less postinst works, the better.
> >
> > But generally speaking, group/permission operations in my observation are
> > quick in the 1st boot. There're other postinst being heavy. :-)
> >
> The more you add to 1st boot that could be done during rootfs creation
> will always add more time, it's better to do it at rootfs time if possible.
> 
> Will you be-able to modify this for 1.0 M3?  If not will there be a plan
> for M4 or 1.1?
> 

Not for 1.0 M3. I would think 1.1 is better given that this task aims to improve
a long-standing issue (but I'll start it in M4 window). So would you accept this
patch (and also at) first since they are trying to fix functional issues? :-)

Thanks
Kevin