On 1/6/08, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote: > On Jan 6, 2008 7:10 PM, Carlo Calica <[EMAIL PROTECTED]> wrote: > > On 1/6/08, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote: > > > > > > I ran some months ago into a case where the uid was expected to be > > > 'x'. I think that was a cron application, I'm not sure. Anyway, having > > > the option there is good. > > > > > Sounds broken. > > Yes, indeed that looked weird. > > > > About conflicts, both useradd and groupadd fails when the number is > > > already assigned to another user, so no worries. > > > > > So what would happen in the above cron when using a uid/gid belonging > > to someone else. > > I think it would just work, as the uid/gid "was there". >
Yeah it should work. May introduce a vulnerability through the shared uid/gid. it would be horrible if cron shared ids with apache. I'd recommend a policy where fixed ids like that start at 99 and work down (avoid ISO shipped 0+, and dynamic 100-999). May need to patch sources, but really the only secure choice. Am I being paranoid? > > I think having it assume a system id makes sense. Add a user keyword > > to override. (I, also, can't imagine a use case but its easy to add, > > just to pass -u to useradd). I can't imagine a difference between > > system/user groups but once you have code to find next system id, > > adding it for groups is easy. > > Ok. Round 2, here we come. Tested with the following input file: > > required_groups=( > "users" > "wontwork gid=1001" > "solo" > "yes gid=900" > ) > required_users=( > "scripts" > "wakeman uid=222 groups=yes,solo" > ) > > Comments? > a nonsystem keyword for required_users? echo "$entry" | grep -q " nonsystem" && unset uid inserted appropriately should work. -- Carlo J. Calica _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
