[lug] group perm nightmare
Michael D. Hirsch
mhirsch at nubridges.com
Mon Oct 7 07:33:52 MDT 2002
I don't have much to add to Chris's comments, other than to say that I
find the RedHat gimmick great. I first learned about it when on a
Solaris system doing a group project (withouth CVS) and we needed
exactly that setup. It makes it easy for groups to share files. You
do need the 002 umask, and redhat sets that by default. I've also used
it pretty much every project I've been on somewhere. I recently used
it to give someone access to /var/www/html on a coporate website with
giving them root permissions.
As for the sys V init stuff, That appears to be a matter of religion
akin to vi vs emacs. I love the ability to start/stop services that
sysv init gives, and the ability to permanently add services to the
startup from a simple command line without editing any files. That
lets me, say, have the postinstall script of an rpm make the service
start at boot, with a one line command.
--Michael
On Sunday 06 October 2002 05:47 pm, chris wrote:
> On Sat, Oct 05, 2002 at 08:26:32AM -0600, Jason W. Strnad wrote:
> > So I know that this is the 'RedHat' way and when in Rome (RedHat?)
> > do as the Romans, etc. But, beyond the benefit of being consistent
> > with the distribution, can anyone tell me the benefit to this
> > user:group arrangement?
>
> redhat claims that coupled with a default umask of 002, it makes
> multi- user development environments easier to maintain without
> constant sysadmin intervention or accidental privatizing of shared
> files:
> http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1
>-users-groups-private-groups.html
>
> while their rationale makes sense, i'm not sure it's as widely
> applicable as they might think. most of the development i've been a
> part of has been fairly single-userrific thanks to cvs (ie i own my
> own local copy of all files in the project, and nobody else is trying
> to access them directly, going rather thru the shared/sanely-perm'd
> cvs respository).
>
> the sgid-directory trick is pretty neat, tho, however kinda useless
> if one's umask is 022 or worse, which is (according to those docs)
> the whole point.
>
> for me, this "user private group" scheme has created more trouble
> than it is worth. there have been several incidents of sendmail
> refusing to use .forwards due to group writable directories/files,
> which is easy enough to solve, but for junior sysadmins, a bit of a
> hassle to find information on (in my experience, anyway. you only
> have to show them the maillog once, though, assuming you have
> debugging output set reasonably).
>
> > Personally, and I come from a BSD background, I find this to be
> > somewhat obnoxious, and something that I work around, rather than
> > something I find useful. I also hate the System-V init scripts
> > that RedHat brought to linux, but I have learned that they bring
> > extra flexibility in certain complicated startup situations.
>
> while sysVinit took a little while to get used to (i came from a
> sunos 4/ slackware/aix background to redhat...) i don't think it's
> inherently much worse. just different. this is a gut feeling, i
> have no technical arguments to back it up.
>
> > I don't mean to start a religious war, and I find RedHat' s distro
> > to be quite good on the whole, but I can't escape the thought that
> > this user:group arrangement is simply gratuitously different. Can
> > anyone shed light on this for me?
>
> i'm a redhat escapee (tho i like most any linux distro better than
> most any other commercial unix), so take my opinion with a grain of
> salt. i still have to support it, and many are the days i find
> something i think to be gratuitous or poorly planned, leaving me
> fuming with RedHate.. then again, i doubt i could do much better.
> rpm, while introducing some serious pain into my life, is also a
> helluva step up from those slackware .tgz's i used to use...
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
More information about the LUG
mailing list