[gobolinux-devel] gobolinux-devel Digest, Vol 20, Issue 19
Michael Tsopeis
michael.tsopeis at gmail.com
Mon Apr 30 08:48:20 UTC 2007
Hello to everyone, I am new to the list, but reading what you were saying
about the numbers of groups the kernel supports, and the way that a finer
user control can be implemented, I urge you to read this: aswl.blogspot.com.
This security layer is already applied on commercial apps and is going to be
released probably under a BSD license. It is created by a friend of mine,
and we have some very specific thins in mind as targets about a distro that
can at last offer the "semantic desktop", without any restriction to the
users, but providing (theoraticaly) impenetrable security. I will provide
you with full details if you like it, but we think that our ideas combined
with Gobo's excellent structure can create a truly revolutionary system.
On 4/28/07, gobolinux-devel-request at lists.gobolinux.org <
gobolinux-devel-request at lists.gobolinux.org> wrote:
>
> Send gobolinux-devel mailing list submissions to
> gobolinux-devel at lists.gobolinux.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
> or, via email, send a message with subject or body 'help' to
> gobolinux-devel-request at lists.gobolinux.org
>
> You can reach the person managing the list at
> gobolinux-devel-owner at lists.gobolinux.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gobolinux-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: /etc/group (Ricardo Nabinger Sanchez)
> 2. Re: Handle unmanaged files in FiboSandbox (and cleaner for
> UnionSandbox) (Hisham Muhammad)
> 3. Re: /etc/group (Jonatan Liljedahl)
> 4. Re: /etc/group (Carlo Calica)
> 5. Re: /etc/group (Ricardo Nabinger Sanchez)
> 6. Re: /etc/group (Jonas Karlsson)
> 7. Re: /etc/group (Carlo Calica)
> 8. Re: /etc/group (Hisham Muhammad)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 25 Apr 2007 11:26:54 -0300
> From: Ricardo Nabinger Sanchez <rnsanchez at wait4.org>
> Subject: Re: [gobolinux-devel] /etc/group
> To: gobolinux-devel at lists.gobolinux.org
> Message-ID: <20070425112654.fddda0fb.rnsanchez at wait4.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 25 Apr 2007 03:00:07 -0300
> "Lucas C. Villa Real" <lucasvr at gobolinux.org> wrote:
>
> > Is that really needed, as we have the 'users' group common to
> > everyone? I would vote for removing it, but I'd just like to hear your
> > opinion first.
>
> It's not needed, and may even hurt manageability. IIRC a user may have be
> part of up to 16 groups, after that only ACL "works".
>
> --
> Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}>
> Powered by FreeBSD
>
> "Left to themselves, things tend to go from bad to worse."
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 25 Apr 2007 11:29:47 -0300
> From: "Hisham Muhammad" <hisham.hm at gmail.com>
> Subject: Re: [gobolinux-devel] Handle unmanaged files in FiboSandbox
> (and cleaner for UnionSandbox)
> To: "Development of the GoboLinux distribution"
> <gobolinux-devel at lists.gobolinux.org>
> Message-ID:
> <5e7d91620704250729q44e6d0f7lfa5d972e5ee605cd at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/25/07, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> > On Wed, 25 Apr 2007 02:29:55 +0200, Hisham Muhammad <hisham.hm at gmail.com
> >
> > wrote:
> >
> > > On 4/24/07, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> > >> Here's a proposed change to fix the handling of unmanaged files a bit
> > >> cleaner at the same time as it adds support for unmanaged files to
> > >> FiboSandbox. In short what it does:
> > >> It adds support for mapped mounts to FiboSandbox. This is implemented
> so
> > >> that for every system directory in the mapped mounts option will have
> a
> > >> corresponding directory in Resources/Unmanaged in the ${target}
> > >> directory,
> > >> which will be bind mounted over the system directory redirecting all
> > >> writes into the system directory to the directory in
> > >> Resources/Unmanaged.
> > >> Easy, huh? :)
> > >> An example:
> > >> /System/Kernel/Modules/$(uname -r)/misc/ndiswrapper.ko is in the
> > >> unmanaged
> > >> file array. Then
> > >> ${target}/Resources/Unmanaged/System/Kernel/Modules/$(uname -r)/misc
> > >> will
> > >> be bind mounted over /System/Kernel/Modules/$(uname -r)/misc, so when
> > >> the
> > >> installer tries to copy the file to /System/Kernel/Modules/$(uname
> > >> -r)/misc it will be redirected, through the mount, to
> > >> ${target}/Resources/Unmanaged/System/Kernel/Modules/$(uname -r)/misc
> > >>
> > >> Union sandbox already had mapped mounts.
> > >>
> > >> Then I made Compile parse the unmanaged_files array and pass it to
> > >> SandboxInstall that made it to mapped mounts, which both FiboSandbox
> and
> > >> UnionSandbox now supports.
> > >
> > > My only fear is that the fact that now the bind-mount is occluding any
> > > existing contents of directories that will receive unmanaged files may
> > > for some strange reason break some recipe. I couldn't think of any
> > > case, but it's a possibility.
> > >
> > If it breaks the recipe, the recipe is already broken. The mounts are
> only
> > done, just before "make install" and are undone right after. As far as
> I'm
> > concerned no other binaries/executables then 'mv','cp' and 'install'
> > should be used during this step, so "hiding" some other
> > binaries/executables should not break anything ("hiding"
> > binaries/executables is the only way I can see that it breaks). At the
> > same time, binaries/executables shouldn't be handled as unmanaged files,
> > i.e. no bin/sbin (or similar directory) should be listed in unmanaged
> > files. Actually the only files I see have to be handled as unmanaged
> files
> > are kernel modules (as they can't be links - yet), other files should be
> > insterted in the "normal" tree.
>
> Agreed.
>
> > > Maybe this new support could be added to FiboSandbox but keep Compile
> > > working with unionfs the same way as it does now (and switch
> > > UnionSandbox behavior to use mapped mounts later)? One problem
> > > implementing this idea is that the use of Union vs Fibo is transparent
> > > to Compile now, AFAIK. OTOH, maybe I'm just being too paranoid.
> > >
> > I can't see what difference you're talking about. The use of Union vs
> Fibo
> > should be transparent with my implementation as well. Now both supports
> > '--map' and both sandboxes use that to handle unmanaged files. There's
> no
> > difference.
>
> Yes, yes. I was thinking about the possiblity of (broken) recipes
> relying on the difference of behavior that used to exist between Fibo
> and Union. But you're right, this shouldn't be a problem in practice.
>
> -- Hisham
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 25 Apr 2007 19:03:50 +0200
> From: Jonatan Liljedahl <lijon at kymatica.com>
> Subject: Re: [gobolinux-devel] /etc/group
> To: Development of the GoboLinux distribution
> <gobolinux-devel at lists.gobolinux.org>
> Message-ID: <462F89F6.4020803 at kymatica.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Lucas C. Villa Real wrote:
> > On 4/25/07, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> >> On Wed, 25 Apr 2007 08:59:20 +0200, Carlo Calica <carlo at calica.com>
> wrote:
> >>
> >>> On 4/24/07, Lucas C. Villa Real <lucasvr at gobolinux.org> wrote:
> >>>> Hello,
> >>>>
> >>>> While checking the bugs reported by Peter I noticed that useradd (the
> >>>> one from Shadow package, invoked by AddUser) automatically creates a
> >>>> group with the same name as the username supplied in the command
> line.
> >>>> Is that really needed, as we have the 'users' group common to
> >>>> everyone? I would vote for removing it, but I'd just like to hear
> your
> >>>> opinion first.
> >>>>
> >>> I say keep it. Groups are cheap.
> >>>
> >> Why is it used? What is the advantage of having one group per user?
> >> Especially when groups can't be members of other groups.
> >
> > A file configured to be owned by foo:foo would be equivalent to
> > configuring it to be owned by foo:users with group bits set to zero,
> > so I really don't see a reason to have this kind of group by default..
>
> I totally agree. I can't see any point in having one group per user.
>
> --
> /Jonatan [ http://kymatica.com ]
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 25 Apr 2007 20:02:11 -0700
> From: "Carlo Calica" <carlo at calica.com>
> Subject: Re: [gobolinux-devel] /etc/group
> To: "Development of the GoboLinux distribution"
> <gobolinux-devel at lists.gobolinux.org>
> Message-ID:
> <e4e91d950704252002y34af1402w33052668d3ced56c at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/25/07, Ricardo Nabinger Sanchez <rnsanchez at wait4.org> wrote:
> > On Wed, 25 Apr 2007 03:00:07 -0300
> > "Lucas C. Villa Real" <lucasvr at gobolinux.org> wrote:
> >
> > > Is that really needed, as we have the 'users' group common to
> > > everyone? I would vote for removing it, but I'd just like to hear your
> > > opinion first.
> >
> > It's not needed, and may even hurt manageability. IIRC a user may have
> be
> > part of up to 16 groups, after that only ACL "works".
> >
>
> A quick google turns up:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.0/0535.html In a
> nutshell, Andrew Morton says "2.6 kernels support up to 65536 groups
> per user". There is a reply saying NFS has problems but I can't
> imagine why. NFS should just report the group and the kernel should
> handle group membership/access control.
>
> Why is it better. It allows users finer grained access control. They
> can share with a subset of users versus all of them. See "man
> gpasswd" on how users can manage /etc/groups without root. Right now,
> users aren't administrators of their group so the advantages really
> aren't there by default but that just needs to be added to AddUser.
>
> >From a practical standpoint it isn't that big of deal. Most GoboLinux
> systems are small with few users and the primary user has root. The
> admin overhead of creating special groups for fine access control is
> small. For larger systems, individual user groups saves a lot of
> admin work when needed. I tend to think towards larger system from my
> university and consulting days.
>
> I still vote for keeping individual groups. All users accounts should
> also be a member of users (which isn't happening). I'd also like
> better distinction between user and system accounts and groups.
>
> --
> Carlo J. Calica
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 26 Apr 2007 11:31:10 -0300
> From: Ricardo Nabinger Sanchez <rnsanchez at wait4.org>
> Subject: Re: [gobolinux-devel] /etc/group
> To: gobolinux-devel at lists.gobolinux.org
> Message-ID: <20070426113110.3066a39d.rnsanchez at wait4.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 25 Apr 2007 20:02:11 -0700
> "Carlo Calica" <carlo at calica.com> wrote:
>
> > A quick google turns up:
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.0/0535.html In a
> > nutshell, Andrew Morton says "2.6 kernels support up to 65536 groups
> > per user". There is a reply saying NFS has problems but I can't
> > imagine why. NFS should just report the group and the kernel should
> > handle group membership/access control.
>
> Yes, but that also assumes NFS over Linux kernels. Which isn't always
> true,
> at least in my house. :)
>
> >
> > Why is it better. It allows users finer grained access control. They
> > can share with a subset of users versus all of them. See "man
> > gpasswd" on how users can manage /etc/groups without root. Right now,
> > users aren't administrators of their group so the advantages really
> > aren't there by default but that just needs to be added to AddUser.
>
> But adding groups per-user is almost what you get by using ACLs.
>
> >
> > >From a practical standpoint it isn't that big of deal. Most GoboLinux
> > systems are small with few users and the primary user has root. The
> > admin overhead of creating special groups for fine access control is
> > small. For larger systems, individual user groups saves a lot of
> > admin work when needed. I tend to think towards larger system from my
> > university and consulting days.
> >
> > I still vote for keeping individual groups. All users accounts should
> > also be a member of users (which isn't happening). I'd also like
> > better distinction between user and system accounts and groups.
>
> That's an interesting point, which could be further discussed (it's a
> everybody-wins discussion).
>
> Like you, I tend to think about large system, often much larger than
> practically acceptable, and also very heterogeneous (very means not only
> Gobo, and even not only Linux).
>
> Even so, I still don't see a point to have per-user groups, instead of
> well-defined (and fine-grained) groups, like cdrom, video, mount, sudo (or
> wheel), and so on. My list hardly goes over 30 groups.
>
> Isn't it possible to the 2 options co-exist? It may be harder, but I
> think
> it's worth it.
>
> --
> Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}>
> Powered by FreeBSD
>
> "Left to themselves, things tend to go from bad to worse."
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 26 Apr 2007 23:50:26 +0200
> From: "Jonas Karlsson" <jonka750 at student.liu.se>
> Subject: Re: [gobolinux-devel] /etc/group
> To: "Development of the GoboLinux distribution"
> <gobolinux-devel at lists.gobolinux.org>
> Message-ID: <op.treuycc2llys5b at localhost.localdomain>
> Content-Type: text/plain; format=flowed; delsp=yes;
> charset=iso-8859-15
>
> On Thu, 26 Apr 2007 05:02:11 +0200, Carlo Calica <carlo at calica.com> wrote:
>
> > On 4/25/07, Ricardo Nabinger Sanchez <rnsanchez at wait4.org> wrote:
> >> On Wed, 25 Apr 2007 03:00:07 -0300
> >> "Lucas C. Villa Real" <lucasvr at gobolinux.org> wrote:
> >>
> >> > Is that really needed, as we have the 'users' group common to
> >> > everyone? I would vote for removing it, but I'd just like to hear
> your
> >> > opinion first.
> >>
> >> It's not needed, and may even hurt manageability. IIRC a user may have
> >> be
> >> part of up to 16 groups, after that only ACL "works".
> >>
> >
> > A quick google turns up:
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.0/0535.html In a
> > nutshell, Andrew Morton says "2.6 kernels support up to 65536 groups
> > per user". There is a reply saying NFS has problems but I can't
> > imagine why. NFS should just report the group and the kernel should
> > handle group membership/access control.
> >
> > Why is it better. It allows users finer grained access control. They
> > can share with a subset of users versus all of them. See "man
> > gpasswd" on how users can manage /etc/groups without root. Right now,
> > users aren't administrators of their group so the advantages really
> > aren't there by default but that just needs to be added to AddUser.
> >
> As already stated, ACL can do that (almost). What's different?
> And besides, having a lot of small groups, one for each user, is the
> opposite on what was decided on the 'cdrecord', 'audio' etc vs 'console'
> groups.
>
> > From a practical standpoint it isn't that big of deal. Most GoboLinux
> > systems are small with few users and the primary user has root. The
> > admin overhead of creating special groups for fine access control is
> > small. For larger systems, individual user groups saves a lot of
> > admin work when needed. I tend to think towards larger system from my
> > university and consulting days.
> >
> > I still vote for keeping individual groups. All users accounts should
> > also be a member of users (which isn't happening). I'd also like
> > better distinction between user and system accounts and groups.
> >
> You got me convinced. I do believe in fine grained control (including
> 'cdrecord' and all) and iirc not all file system supports ACL (and they
> have to actively be selected in the kernel config).
>
> --
> /Jonas
>
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 26 Apr 2007 23:04:36 -0700
> From: "Carlo Calica" <carlo at calica.com>
> Subject: Re: [gobolinux-devel] /etc/group
> To: "Development of the GoboLinux distribution"
> <gobolinux-devel at lists.gobolinux.org>
> Message-ID:
> <e4e91d950704262304n218a89ahe3e3a7d9b9f84211 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/26/07, Ricardo Nabinger Sanchez <rnsanchez at wait4.org> wrote:
> > On Wed, 25 Apr 2007 20:02:11 -0700
> >
> > But adding groups per-user is almost what you get by using ACLs.
> >
>
> True.
>
> >
> > Like you, I tend to think about large system, often much larger than
> > practically acceptable, and also very heterogeneous (very means not only
> > Gobo, and even not only Linux).
> >
> > Even so, I still don't see a point to have per-user groups, instead of
> > well-defined (and fine-grained) groups, like cdrom, video, mount, sudo
> (or
> > wheel), and so on. My list hardly goes over 30 groups.
> >
> > Isn't it possible to the 2 options co-exist? It may be harder, but I
> think
> > it's worth it.
> >
> Those are orthogonal issues. per-user groups allow "friends of mine"
> sharing between subsets of all users. This is NOT administrative
> policy but choices that each user can make. "well-defined groups"
> sets admin policy, for how sets of users can access the system.
>
> There was a thread about the udev recipe on whether to unify
> cdrom,video,audio into a single console group (sorry, don't remember
> the outcome). That and this are really the same issue. Fine grained
> control vs simplicity. As a distro we need to choose a path and
> follow it.
>
> --
> Carlo J. Calica
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 27 Apr 2007 22:39:32 -0300
> From: "Hisham Muhammad" <hisham.hm at gmail.com>
> Subject: Re: [gobolinux-devel] /etc/group
> To: "Development of the GoboLinux distribution"
> <gobolinux-devel at lists.gobolinux.org>
> Message-ID:
> <5e7d91620704271839v7564da6dh478e390155ac266c at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/27/07, Carlo Calica <carlo at calica.com> wrote:
> > There was a thread about the udev recipe on whether to unify
> > cdrom,video,audio into a single console group (sorry, don't remember
> > the outcome). That and this are really the same issue. Fine grained
> > control vs simplicity. As a distro we need to choose a path and
> > follow it.
>
> I've been following this thread as a distant observer and have no
> technical opinion on the matter, but in general, I think we should,
> for a default setup, favor simplicity over fine grained control in
> what concerns system administration. While Gobo is a general-purpose
> operating system, I think we all agree that its default setup is
> desktop-oriented. A potential server-oriented edition would have
> things set up differently, for sure. Now that the build system for the
> ISO is getting more modular, I hope to see variations of the main
> desktop-oriented ISO appearing sooner than later. Alternative desktop
> environments would be a possibility, but a server-oriented setup would
> be very nice to have as well.
>
> -- Hisham
>
>
> ------------------------------
>
> _______________________________________________
> gobolinux-devel mailing list
> gobolinux-devel at lists.gobolinux.org
> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
>
>
> End of gobolinux-devel Digest, Vol 20, Issue 19
> ***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gobolinux.org/pipermail/gobolinux-devel/attachments/20070430/1f6492de/attachment-0001.htm
More information about the gobolinux-devel
mailing list