| Summary: | sys-process/vixie-cron: Inconsistency of cron related group handling | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Zhang Le (RETIRED) <r0bertz> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | enhancement | CC: | cron-bugs+disabled, falco, treecleaner, wolf31o2 |
| Priority: | High | Keywords: | PMASKED |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Deadline: | 2019-10-11 | ||
|
Description
Zhang Le (RETIRED)
2008-03-24 16:29:14 UTC
Please say something. Which way to go. Leave the current status as it is, or make all cron daemon use two groups, or make all cron daemon use just cron group. We need to make a decision, then update documentation accordingly. Thanks! the introduction of the crontab group has been a uncoordinated effort by the vixie-cron maintainer (i guess).... i dont know exactly how you expect the other cron maintainers to react to it. in order to react to it, it would be nice to hear the rationale for creating the group in the first place - second hand guessing as to why that 'feature' was introduced does not get me anywhere. unfortunately -r10 is already stable, otherwise i would have called for p.masking it... (In reply to comment #2) > i dont know exactly how you expect the other cron maintainers to react to it. > in order to react to it, it would be nice to hear the rationale for creating > the group in the first place Exactly. Actually I don't have any strong preference over any of those solutions I've proposed. However, I think maybe it'll be better that all the cron implementations conform to the same rule, ie. either all separate crontab group from cron group or all use just one cron group. JFYI, fcron for example doesn't use the cron group thingy at all, as it has a different security model -- it's using its own user and group fcron for a different reason though (least privilege principle). (In reply to comment #4) > JFYI, fcron for example doesn't use the cron group thingy at all, as > it has a different security model -- it's using its own user and group fcron > for a different reason though (least privilege principle). Thanks for sharing this. until we know why the normal 'cron' group isnt good enough for vixie-cron, we cant really make a decision. dcron only needs 1 crontab group and it uses the standard 'cron' like it should. falco: it appears, you added the crontab group stuff. could you please explain yourself? thanks... falco? i guess, we'll revert the stuff then?! Can we get some movement on this, even if it is just to assign it to QA to make a decision? This is a very small change to be done, if reverting, so there's really no excuse for it to sit around for nearly a year with 0 activity. Hi, sorry for not having noticed this bug. :) the root reason is https://bugs.gentoo.org/164466. The new "crontab" group is the group under /usr/bin/crontab is to be executed (SGID). With the ancient behaviour, /usr/bin/crontab was SUID, which was unnecessary. This choice (SGID versus SUID) is inspired by Debian and other distros. On Gentoo, the "cron" group, which has not the same meaning, has been existing long before me. If it is possible to merge the "cron" and "crontab" group into one single group, then i'm OK for sure. BTW "severity=major" looks a little strong for that entry :) Package removed. |
