On Tue, March 2, 2010 15:12, Paul B. Henson wrote:
On Tue, 2 Mar 2010, David Dyer-Bennet wrote:
Hmmm; the lack of flexibility you talk about comes from not using the
security model sensibly -- having per-person groups is very useful in
that security model.
I have 70 odd thousand users. Why
On Wed, 3 Mar 2010, David Dyer-Bennet wrote:
It's the normal way to do it; not sure where in the Linux world it arose,
but I first saw it in some early distribution. It's done automatically by
adduser. In my perception, it's best practice. So the question is,
why do you NOT want to do it?
On Wed, March 3, 2010 10:23, Paul B. Henson wrote:
On Wed, 3 Mar 2010, David Dyer-Bennet wrote:
It's the normal way to do it; not sure where in the Linux world it
arose,
but I first saw it in some early distribution. It's done automatically
by
adduser. In my perception, it's best
On Wed, 3 Mar 2010, David Dyer-Bennet wrote:
I don't think it will work as well for you as you think it will; I think
you'll then find yourself complaining that backup systems don't work, and
indexing systems don't work, and this doesn't work, and that doesn't work,
all because you've broken
On Mon, March 1, 2010 23:04, Paul B. Henson wrote:
If users have private primary groups then you can have them run with
umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure that
users can share files in specific directories. (This is one reason that
I recommend always giving
I haven't been really closely following this discussion, but I might
have a solution.
A quick glance at 'man chmod(1)' will show that there is an unused bit
in the file mask, namely '7000'. This has been there for quite a long
time. I discovered it in '94 when a student accidentally set it on her
Logically it would be setuid + setgid + sticky, but it is not defined
in the man page and I don't have the ability to read through the
applicable source code. If it's not available, then I retract my
suggestion, and instead suggest that the man pages need to be updated.
:)
According to the man
On 2 March 2010 08:13, Fredrich Maney fredrichma...@gmail.com wrote:
I haven't been really closely following this discussion, but I might
have a solution.
A quick glance at 'man chmod(1)' will show that there is an unused bit
in the file mask, namely '7000'.
Isn't that just like having
On 2 March 2010 10:35, Fredrich Maney fredrichma...@gmail.com wrote:
Logically it would be setuid + setgid + sticky, but it is not defined
in the man page and I don't have the ability to read through the
applicable source code. If it's not available, then I retract my
suggestion, and instead
On 03/02/10 08:13, Fredrich Maney wrote:
Why not do the same sort of thing and use that extra bit to flag a
file, or directory, as being an ACL only file and will negate the rest
of the mask? That accomplishes what Paul is looking for, without
breaking the existing model for those that need/wish
I strongly suggest that folks who are thinking about this examine what
NetApp does when exporting NTFS security model qtrees via NFS. It
constructs a mostly bogus set of POSIX permission info based on the ACL.
All access is enforced based on the actual ACL. Sadly for NFSv3 clients
there is no
On 02 March, 2010 - Carson Gaspar sent me these 0,5K bytes:
I strongly suggest that folks who are thinking about this examine what
NetApp does when exporting NTFS security model qtrees via NFS. It
constructs a mostly bogus set of POSIX permission info based on the ACL.
All access is
Tomas Ögren wrote:
On 02 March, 2010 - Carson Gaspar sent me these 0,5K bytes:
I strongly suggest that folks who are thinking about this examine what
NetApp does when exporting NTFS security model qtrees via NFS. It
constructs a mostly bogus set of POSIX permission info based on the ACL.
On Tue, Mar 02, 2010 at 11:10:52AM -0800, Bill Sommerfeld wrote:
On 03/02/10 08:13, Fredrich Maney wrote:
Why not do the same sort of thing and use that extra bit to flag a
file, or directory, as being an ACL only file and will negate the rest
of the mask? That accomplishes what Paul is
car...@taltos.org said:
NetApp does _not_ expose an ACL via NFSv3, just old school POSIX mode/owner/
group info. I don't know how NetApp deals with chmod, but I'm sure it's
documented.
The answer is, It depends. If the NetApp volume is NTFS-only permissions,
then chmod from the Unix/NFS
On Tue, Mar 02, 2010 at 11:42:30AM -0800, Carson Gaspar wrote:
NetApp does _not_ expose an ACL via NFSv3, just old school POSIX
mode/owner/group info. I don't know how NetApp deals with chmod, but
I'm sure it's documented.
I can't get a chmod to succeed in that situation. This particular
On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
no. what happens when an NFS client without ACL support mounts your
filesystem? your security is blown wide open. the filemode should
reflect the *least* level of access. if the filemode on its own allows
more access, then you've lost.
Say
On Tue, 2 Mar 2010, David Dyer-Bennet wrote:
Hmmm; the lack of flexibility you talk about comes from not using the
security model sensibly -- having per-person groups is very useful in
that security model.
I have 70 odd thousand users. Why would I want to also have 70 thousand
groups with
On Tue, 2 Mar 2010, Bill Sommerfeld wrote:
While we're designing on the fly: Another possibility would be to use an
additional umask bit or two to influence the mode-bit - acl interaction.
I've think trying to continue shoving a square page into a round hole is
simply the wrong thing to do;
On Tue, 2 Mar 2010, Marion Hakanson wrote:
The answer is, It depends. If the NetApp volume is NTFS-only
permissions, then chmod from the Unix/NFS side doesn't work, and you can
only manipulate permissions from Windows clients.. If it's a mixed
security-style volume, chmod from the Unix/NFS
On Mon, Mar 01, 2010 at 09:04:58PM -0800, Paul B. Henson wrote:
On Mon, 1 Mar 2010, Nicolas Williams wrote:
Yes, that sounds useful. (Group modebits could be applied to all ACEs
that are neither owner@ nor everyone@ ACEs.)
That sounds an awful lot like the POSIX mask_obj, which was the
Yes. Yes. Yes. I agree with every one of your points in this message :).
On Tue, 2 Mar 2010, Nicolas Williams wrote:
Well, I think the bit, if we must have one, belongs in the filesystem
objects that have ACLs, as opposed to processes. There may be no umask
to apply in remote access cases,
Paul B. Henson hen...@acm.org writes:
On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
no. what happens when an NFS client without ACL support mounts your
filesystem? your security is blown wide open. the filemode should
reflect the *least* level of access. if the filemode on its own
BTW, it should be relatively easy to implement aclmode=ignore and
aclmode=deny, if you like.
- $SRC/common/zfs/zfs_prop.c needs to be updated to know about the new
values of aclmode.
- $SRC/uts/common/fs/zfs/zfs_acl.c:zfs_acl_chmod()'s callers need to be
modified:
- in the create
I find myself agreeing with Paul on this one. We allow people to
choose between filesystems, volume managers, password encryption
algorithims, profiles, etc. Why not allow them to pick one file
security model, another, or both?
Now, of course, the devil is in the details of implementation. Do we
On Tue, 2 Mar 2010, Nicolas Williams wrote:
If no modebits were to apply to ACEs with subjects other than
owner@/group@/everyone@ (what about subjects that match the file's
owner/group but aren't owner@/gr...@?) then there'd be no way to use
modebits as a big filter for ACLs. This is why I
On Tue, 2 Mar 2010, Nicolas Williams wrote:
BTW, it should be relatively easy to implement aclmode=ignore and
aclmode=deny, if you like.
I looked over the code some, and from an intuitive point of view it didn't
seem like it would be that hard; thanks for the pointers.
I'm absolutely willing
On Tue, 2 Mar 2010, Fredrich Maney wrote:
We allow people to choose between filesystems, volume managers, password
encryption algorithims, profiles, etc. Why not allow them to pick one
file security model, another, or both?
Choice is good :).
Now, of course, the devil is in the details of
On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
this is true for AUTH_SYS, too, sorry about the bad example.
Technically I suppose the server actually makes the determination about
access, but given it makes it based blindly on whatever the client tells
it, it seems it's really the client with
Paul B. Henson hen...@acm.org writes:
Good :). I am certainly not wedded to my proposal, if some other
solution is proposed that would meet my requirements, great. However,
pretty much all of the advice has boiled down to either ACL's are
broken, don't use them, or why would you want to do
On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
you haven't demonstrated why the current capabilities are insufficient
for your requirements. it's a bit hard to offer advice for perceived
problems other than reconsider your perception.
I think I've made it pretty clear that I want to control
pbh == Paul B Henson hen...@acm.org writes:
pbh the inability to apply an ACL to a file kind of sucked.
It was not a stupid limitation: You can still apply simple,
easily-understood UNIX ACL's to files because the separate rulespaces
are ANDed together, but if you want baroque if-OR-then
On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin wrote:
nw == Nicolas Williams nicolas.willi...@sun.com writes:
nw What could we do to make it easier to use ACLs?
1. how about AFS-style ones where the effective permission is the AND
of the ACL and the unix permission? You
dd == David Dyer-Bennet d...@dd-b.net writes:
dd Okay, but the argument goes the other way just as well -- when
dd I run chmod 6400 foobar, I want the permissions set that
dd specific way, and I don't want some magic background feature
dd blocking me.
This will be true either
On 03/01/10 13:50, Miles Nordin wrote:
dd == David Dyer-Bennetd...@dd-b.net writes:
dd Okay, but the argument goes the other way just as well -- when
dd I run chmod 6400 foobar, I want the permissions set that
dd specific way, and I don't want some magic background feature
On Mon, March 1, 2010 15:50, Miles Nordin wrote:
dd == David Dyer-Bennet d...@dd-b.net writes:
dd Okay, but the argument goes the other way just as well -- when
dd I run chmod 6400 foobar, I want the permissions set that
dd specific way, and I don't want some magic background
--On Monday, March 01, 2010 03:21:42 PM -0600 Nicolas Williams
nicolas.willi...@sun.com wrote:
On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin wrote:
nw == Nicolas Williams nicolas.willi...@sun.com writes:
nw What could we do to make it Re: [zfs-discuss] Who is using ZFS
ACL's
On Sun, 28 Feb 2010, Kjetil Torgrim Homme wrote:
why are you doing this? it's inherently insecure to rely on ACL's to
restrict access. do as David says and use ACL's to *grant* access. if
needed, set permission on the file to 000 and use umask 777.
Umm, it's inherently insecure to rely on
On Mon, 1 Mar 2010, Nicolas Williams wrote:
Yes, that sounds useful. (Group modebits could be applied to all ACEs
that are neither owner@ nor everyone@ ACEs.)
That sounds an awful lot like the POSIX mask_obj, which was the bane of my
previous filesystem, DFS, and which, as it seems history
Paul B. Henson hen...@acm.org writes:
On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
I think of using ACLs to extend extra access beyond what the
permission bits grant. Are you talking about using them to prevent
things that the permission bits appear to grant? Because so long as
they're
Paul B. Henson wrote:
I've been surveying various forums looking for other places using ZFS ACL's
in production to compare notes and see how if at all they've handled some
of the issues we've found deploying them.
So far, I haven't found anybody using them in any substantial way, let
alone
On 26/02/2010 00:56, Paul B. Henson wrote:
I've been surveying various forums looking for other places using ZFS ACL's
in production to compare notes and see how if at all they've handled some
of the issues we've found deploying them.
Anyone sharing files over CIFS backed by ZFS is using
On 2/25/2010 10:24 PM, Paul B. Henson wrote:
The main ACL problem we've having now (having resolved most of
them, yay) is interaction with chmod() and legacy mode bits, and the
disappointing ease with which an undesired chmod can completely destroy an
ACL.
examples?
Are you using
On Fri, 26 Feb 2010, Ian Collins wrote:
One of my clients makes extensive use of ACLs. Some of them are so
complex, I had to write them an application to interpret and manage them!
Yah, manipulating them directly isn't for the faint of heart ;). But it's
not too hard to abstract them to a
On Fri, 26 Feb 2010, Darren J Moffat wrote:
Anyone sharing files over CIFS backed by ZFS is using ACLs, particularly
when there are only Windows clients. There are large number and some
very significant in size deployments.
If you're running the opensolaris in-kernel CIFS server, you avoid
I think most people are just confused by ACL's, i know i was when i first
started using them. Having said that, once i got them set correctly, they
work very well for my CIFS shares.
On Fri, Feb 26, 2010 at 11:23 AM, Paul B. Henson hen...@acm.org wrote:
On Fri, 26 Feb 2010, Darren J Moffat
On Fri, 26 Feb 2010, Thomas Burgess wrote:
I think most people are just confused by ACL's, i know i was when i first
started using them. Having said that, once i got them set correctly,
they work very well for my CIFS shares.
Are you using the in-kernel CIFS server or samba? Are the files
On Fri, Feb 26, 2010 at 08:23:40AM -0800, Paul B. Henson wrote:
So far it's been quite a struggle to deploy ACL's on an enterprise central
file services platform with access via multiple protocols and have them
actually be functional and reliable. I can see why the average consumer
might give
On Fri, 26 Feb 2010, Nicolas Williams wrote:
Can you describe your struggles? What could we do to make it easier to
use ACLs? Is this about chmod [and so random apps] clobbering ACLs? or
something more fundamental about ACLs?
I understand and accept that ACL's are complicated, and have no
On Fri, 26 Feb 2010, Jason King wrote:
Did you try adding:
nfs4: mode = special
vfs objects = zfsacl
To the shares in smb.conf? While we haven't done extensive work on
S10, it appears to work well enough for our (limited) purposes (along
with setting the acl properties to
On 02/26/10 10:45, Paul B. Henson wrote:
I've already posited as to an approach that I think would make a pure-ACL
deployment possible:
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html
Via this concept or something else, there needs to be a way to configure
nw == Nicolas Williams nicolas.willi...@sun.com writes:
nw What could we do to make it easier to use ACLs?
1. how about AFS-style ones where the effective permission is the AND
of the ACL and the unix permission? You might have to combine this
with an inheritable-by-subdirectories
On Fri, 26 Feb 2010, Bill Sommerfeld wrote:
I believe this proposal is sound.
Mere words can not express the sheer joy with which I receive this opinion
from an @sun.com address ;).
There are already per-filesystem tunables for ZFS which allow the system
to escape the confines of POSIX
On Fri, February 26, 2010 12:45, Paul B. Henson wrote:
I've already posited as to an approach that I think would make a pure-ACL
deployment possible:
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html
Via this concept or something else, there needs to be a
On Fri, Feb 26, 2010 at 02:50:05PM -0800, Paul B. Henson wrote:
On Fri, 26 Feb 2010, Bill Sommerfeld wrote:
I believe this proposal is sound.
Mere words can not express the sheer joy with which I receive this opinion
from an @sun.com address ;).
I believe we can do a bit better.
A chmod
On Fri, 26 Feb 2010, Nicolas Williams wrote:
I believe we can do a bit better.
A chmod that adds (see below) or removes one of r, w or x for owner is a
simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
modifying / replacing / adding owner@ ACEs (if there is one). A
On Fri, Feb 26, 2010 at 04:26:43PM -0800, Paul B. Henson wrote:
On Fri, 26 Feb 2010, Nicolas Williams wrote:
I believe we can do a bit better.
A chmod that adds (see below) or removes one of r, w or x for owner is a
simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
On Fri, 26 Feb 2010, Nicolas Williams wrote:
Suppose you deny or ignore chmods. Well, how would you ever set or reset
set-uid/gid and sticky bits? chmod(2) deals only in absolute modes, not
relative changes, which means that in order to distinguish those bits
from the rwx bits the
On 02/26/10 17:38, Paul B. Henson wrote:
As I wrote in that new sub-thread, I see no option that isn't surprising
in some way. My preference would be for what I labeled as option (b).
And I think you absolutely should be able to configure your fileserver to
implement your preference. Why
On Fri, 26 Feb 2010, Bill Sommerfeld wrote:
acl-chmod interactions have been mishandled so badly in the past that i
think a bit of experimentation with differing policies is in order.
I volunteer to help test discard and deny :). Heck, I volunteer to help
*implement* discard and deny...
On 2/26/2010 6:26 PM, Paul B. Henson wrote:
On Fri, 26 Feb 2010, Nicolas Williams wrote:
I believe we can do a bit better.
A chmod that adds (see below) or removes one of r, w or x for owner is a
simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
modifying / replacing
On 2/26/2010 6:52 PM, Paul B. Henson wrote:
On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
chown ddb /path/to/file
chmod 640 /path/to/file
I'll tell you, if I type that and then find I (I'm ddb) *can't* read the
file, I'm going to be REALLY unhappy.
Then clearly you should
I was in the middle of a lengthy reply to this, which I've abandoned, as it
can pretty much be summarized as If you don't want this behavior, don't
enable it.
It wouldn't be the default, and if you didn't want it, you wouldn't enable
it. Perhaps it might be enabled on some system you inherit,
On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
So, even if you're willing to completely discard 30 years of legacy
scripts and applications -- how to you propose that a NEW script or
application should be written so as to work in this brave new
environment?
[...]
And how should new utilities
On 2/26/2010 8:45 PM, Paul B. Henson wrote:
On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
So, even if you're willing to completely discard 30 years of legacy
scripts and applications -- how to you propose that a NEW script or
application should be written so as to work in this brave new
On Thu, 25 Feb 2010, Marion Hakanson wrote:
It's not easy to get them right, and usually the hardest task is in
figuring out what the users want, so we don't use them unless the users'
needs cannot be met using traditional Unix/POSIX permissions.
We've got a web GUI that hides the complexity
On Thu, 25 Feb 2010, Marion Hakanson wrote:
It's not easy to get them right, and usually the hardest task is in
figuring out what the users want, so we don't use them unless the users'
needs cannot be met using traditional Unix/POSIX permissions.
Yeah, I've had nothing but horror from
67 matches
Mail list logo
