[Novalug] How to change a file's permission question

James Ewing Cottrell 3rd JECottrell3@Comcast.NET
Wed Aug 29 19:49:46 EDT 2012


On 8/29/2012 11:53 AM, Peter Larsen wrote:
> On Tue, 2012-08-28 at 18:16 -0400, James Ewing Cottrell 3rd wrote:
>> On 8/28/2012 3:56 PM, Peter Larsen wrote:
>>> On Tue, 2012-08-28 at 15:14 -0400, James Ewing Cottrell 3rd wrote:
>
> So let's get rid of those assumptions once and for all. I ALWAYS have to
> check chmod's man page because I use it so rarely now. I can never
> remember if it's o for owner, or u for user (yes, I prefer to do my
> scripts symbolically instead of pretending to overwrite a mask with
> octets). I also have to check the symbols for sticky and permission
> bits.

I agree, whoever wrote chmod erred...I would rather have seen [ogw] for 
owner, group, world, like the other documentation references it. Still, 
Real Programmers mostly use Numbers, or use the A for All, which 
defaults. As for SUID/GUID/STICKY, my mnemonic is that SUID is More 
{Important,Dangerous} and Sticky is the Least.

>>>> [1] they haven't traditionally been supported via NFS
>>>
>>> Well, since NFS4 (2006?) this hasn't been an issue. And even before
>>> that, we had examples of NFS versions that supported it. I would go as
>>> far as to say, that most NFS implementations I know fully ignores file
>>> based security all together. So I'm not sure how valid that reason is.
>>
>> Well, I have been using UNIX since the mid 80s, that's 20 Years vs half
>> a dozen or so.
>
> Personally I really don't use what we did in the 70s and 80s as a guide
> for how things should be done today. Requirements and capabilities have
> changed. Use the tools you have now, and you'll find yourself doing more
> with less (commands for instance).

It's a Balance. I certainly use newer stuff, but never everything new is 
golden.

>>>> [2] Ken and DMR didn't see fit to put them in
>>>
>>> Well, aren't we talking 1970'ies now?? Is that really the measurement of
>>> what makes sense?
>>
>> You Bet! There was a time when people Actively Guarded putting in
>> "Feechurs" into UNIX, because One Man's Great Idea is Another Man's Gag
>> Reflex. Look at Solaris 'Doors'...WTF?!? For that matter, look at
>> Microsoft's 'Windows'. But that was just a Joke, and a cheap Shot too,
>> but it was FUN!
>
> Not sure how's that's relevant? Lots of new ideas were adopted too.
> Using this kind of argument, ALL ideas are good and should be adopted?

No, just the Good ones. But that requires Taste, which is an Elusive 
Quality.

> In other words, you have to look at the merits of each feature - so
> let's concentrate on discussing the merits of ACLs - and not everything
> else.

Yes.

>>
>> Now I am not saying that any system is ever Complete, but not ever
>> Addition has been done Tastefully. Like System V IPC.
>
> I'll let that stand. Not sure what "tastefully" means given the prior
> statement.

Sorry for the typo. not EVERY Addition. System V IPC is pretty lame. 
Good features, Bad Implementation. IPC Objects should be Files.

>>>> [3] They really aren't necessary
>>>
>>> Ehhh - show me how you are going to give r/o access to group "users" and
>>> r/w to "accountans" but deny all others with standard linux file
>>> attributes....
>>
>> You need to create a different group and use two levels. So you have:
>>
>> /path/one/two/object.
>> /path/one     needs to be group 'reader' with mode 750
>> /path/one/two needs to be group 'writer' with mode 775
>
>> the objects cannot be writable to the 'reader' group (group 'writer' and
>> mode 664 works). In practice, group 'writer' can simply be 'accountans'.
>>
>> Everyone in the 'writer' group needs to be in the 'reader' group.
>
> So, when someone comes to you and tells you that user X is bad and needs
> to be denied access, how are you going to handle that? Of course you can
> remove him from the groups - however if those groups are used for other
> functionality it has wider implications.  Or adding two writer groups?

Yes, delete him from the Group. Wouldn't you have to do this with the 
ACLs too? Nailing down the entire Hypothetical Design would be difficult 
without knowing the entire Design Constraints, but I would say that 
every Special Object might need it's own Reader/Writer Group.

> I like the attempt for simplification. But it's extremely limited
> because of it. I presume you agree that it cannot do but a fraction of
> what we do with ACLs.

You gave one example. But you also mentioned Groups containing Other 
Groups, which might be nice.


> So I presume the argument will go from this to "do
> we need anything that advanced?"

Possibly. I didn't make that argument here, but I have before.

>>
>> Of course, group 'users' probably includes everyone, so just make it
>> world readable.
>
> Well, I wasn't specifically thinking standard group names. But in
> general, users exclude everything but real users. So no demon access
> etc. In the end, the group names were arbitrary.

Right, but if everyone is in their own group, then all REAL Groups will 
be in /etc/group. And if Corporations are People, then Daemons are Users 
too. Consider that a Joke.

>> Like I mentioned, the REAL solution is to allow a path to have
>> supplemental groups as well, not invent some New Feature.
>
> But you are?

No, I am Extending the Group Concept, from a Scalar to an Array. Just 
like BSD did with Supplemental Groups.

>> Seriously, wouldn't that have been MUCH easier to do???
>>
>> The above example could be expressed as: objects in /path/app/object
>>
>> chgrp -n 0 accountans /path/app; chmod -n 0 2770
>> chgrp -n 1 user       /path/app; chmod -n 1  750
>
> Not even close. ACLs have a lot more features, including default and
> masks. Access and management of access can be quite a bit more
> complicated in particular on shared storage.

More Feaures = More Complicated = More Possibility to Botch = Not UNIX

> So going back to why don't we use ACLs - what I have seen is that it's
> implemented higher up in the stack now. Instead of being implemented by
> the OS, it's implemented by the application server which links to LDAP,
> does ACLs and much much more; all making it very easy to get things
> corrupted and we've started the circle all over again.

Thank you for making my argument for me..."easier to be corrupted". Add 
to that the fact that LDAP has it's own Funny Quirks and you pretty much 
see why many companies have ACL/Group Access nightmares.

> It's the reason I don't buy the argument that ACLs are dead. They're all
> over - but somehow "we" have chosen to move them away from the OS.

I agree. Other places they might show up is VCS and CMNS Repos. Or 
Firewalls. You weren't really serious about putting Accounting Data on 
Servers where the Engineers could Logon were you?!? I think not.

>> In this case, the -n refers to which group/mode pair is changed. Access
>> is granted if any pair grants access.
>>
>> LS simply prints additional lines for group and mode if needed. Stat
>> needs an extra field to print the number of group/mode pairs. Heck,
>> maybe we can have multiple owners as well?!? And some syntax is needed
>> to support deleting extra owner/group/mode triples. And system calls
>> need to be extended to support all this.

Yes, they do, but in More or Less Compatible ways. You may have 
forgotten the BSD changes, but there were some hiccups then too.

chmod -d 2 file  # deletes MOG rule 2
chmod -d plarsen # deletes the plarsen Group rule(s)
chmod -D plarsen # deletes the plarsen Owner rule(s)

Yes, why couldn't we have Multiple Owners? MOG simply becomes an Array.

In the Real World, Joint Ownership exists. SUID would simply ADD new 
Owner privs, and we could get rid of the confusing SETUID

> Right - so you want to change ls, one of the most used commands for
> scripting, and give it multi-line output per file?

With multiple MOG (mode/owner/group) entries, ls would have to change. 
We can always add another option or two to either duplicate all the 
other lines, or do [mode owner group...] size links date file

But just like how Processes have a Primary UID and GID, I might specify 
that Files also did, and that only this one would be displayed without a 
specific option.

> Talk about a
> disruptive impact. I saw what happened when "df" and "mount" on Fedora
> started reporting the same mount points from all it's logical anchors
> perspective - scripts left and right failed as they didn't expect
> duplicate paths to be returned.

I dunno, my design isn't complete, but I'd say that the output of ls is 
Not Sacred and even produces different number of fields in some cases.

I'd say that df and mount formats Aren't Sacred either, just like ps.

If you are calling for Parsable Output, I will Second the Motion.

> So from an "elegance" perspective (is that what you mean by tasteful?)
> FACLs are much smoother, and more powerful than trying to bang a feature
> into this.

Yes, when I say Tasteful, I mean Elegant. Just like Processes have 
Multiple Groups, Files can too. The Berkeley folks only did Half the 
Job. Which at the time, solved Most of their Problems.

FACLs are the "New Feature". Extending the Old Permissions is More Elegant.

>> But an Extension is So Much Better than a New Incompatible Mechanism.
>
> Ehhh - what "incompatible" do you see? I see none with FACLs - it works
> great in conjunction with the existing backwards compatible access
> control system in Linux file systems.

Well, for one, if you are diagnosing Access Problems, you have to look 
thru Two Different Systems...Basic Permissions and ACLs.

But thanks...now I have an extra thing to say to certain Interview 
Questions ;)

> Yours on the other hand, would
> break quite a bit - and I'm not sure how you would implement it on a
> file system that allowed you to be backwards compatible on the EXT specs
> on top of the script issues I mentioned above.

Make the 0'th rule the Primary MOG.

As I said, NONE of the formats mentioned are Sacred, but I would Agree 
to make the Default action print Only the Zero'th Rule...so you have the 
Same Format.

>>>> As a matter of fact, people don't use Groups to their Full Potential.
>>>
>>> No argument there.
>>
>> So...what makes you think people will use ACLs in a better way? I came
>> across an interesting article:
>
> ACLs are in use. All over. Every IDM I've come across uses them. Every
> application, from portals to basic web-apps uses them. And some even
> extends on the user/group idea adding other dimensions that we don't
> have on Linux (yet).

IDM = ID Management?

> Can they be used wrong? Sure! Standard Posix file security is used wrong
> all the time too. It comes down to the admin after all - and to err is
> human, and to be unaware of features is epedemic So the results follow
> that.
>
>> http://www.softpanorama.org/Articles/slightly_skeptical_view_on_unix_acl.shtml
>
> Where to begin .... ?
>
>
>> "For example, GNU tar won't back up or restore ACLs, and NFS in
>> FreeBSD ignores them too"
>
> Wrong - gnu tar has options to include ACLs.

Well, the page could be wrong, but the date was 2011, pretty recent. But 
what about the Backups? Does every one (Legato, NetBackup, etc) 
implement every wacko system ("adding other dimensions") that people 
choose to incorporate into their system? What about other Metadata, like 
"Resource Forks"? Those are Bad Ideas too.

I'm not a fan of BSD these days, but I'd hate to import an Application 
that required ACLs only to find they weren't supported.

>> "An ACL is user based and "project" on filesystem set of permissions
>> defined for each user. That conflicts with Unix traditional model and
>> a net result is mess."
>
> ACLs are not always user specific. And I'm still not seeing the mess
> either.

To be honest, I'm not sure what the first sentence is getting at. It was 
the second that I was after. The point is that many other people seem to 
share my sentiment.

>> "Especially tricky are so called default permissions for user and
>> group."
>
> How so? You add the -d to the setfacl? If everything else fails, that
> line wins - regardless of where it is in the sequence. He may be
> confusing this with the mask, but let's not overcomplicate things here.

I'm not sure what he means here either.

>> "For example, you might have two groups that need permission to access
>> a file, one to read it and one to write to it.

So he came up with your example, but wasn't as clever as I was about 
Solving it.

>> Alternatively, you
>> might have a file that you wanted everyone in a group to be able to
>> read, so you would give group read permissions on that file. Suppose
>> that you want only two people in the group to be able to write to that
>> file.

This is the standard problem of Groups being Too Big. I you want All 
Accountants Except Fred to have access, you Need Another Group.

>> With standard UNIX permissions, you cannot give write permission
>> to only two members of a group. And you can't set a second group as
>> file is owned by a single group.

Solution...Multiple MOG triples!

>> You can, however, set up an ACL for
>> that file to grant only two people in the group write permissions on
>> that file."
>
> Right - use case for ACLs penned out for us here.

Or...you could Extend the MOG Scalar into an Array, just like with User 
Supplemental Groups.

>> "What is important, ACLs solve one very significant Unix limitation:
>> the fact that group cannot contain other groups."
>
> After he's just spend time explaining that you cannot limit to only
> specific members of a group, I fail to see how he can conclude that it's
> only about group nesting.

He didn't say Only...You did. However, something that could even be don 
with today's /etc/group file is to extend the syntax as follows:

hipsters: alice,bob,@novalug,-pryzby,-@hackers,trudy

It would take a bit longer to login, but you would be put in the right 
groups, but that beats the mutiple tests on each file access.

So Alice, Bob, anyone from the Novalub Group except Greg, and no one 
from the group Hackers, except Trudy, who is in the Hacker Group would 
be in the Hipster Group.

>> "In many cases those cases can be solved by creating a new group with
>> a particular membership. But in general proliferation of groups make
>> them difficult to understand and maintain. Also most Unixes have
>> limitation on the number of groups a user can be member of.

Yes, Traditionally 8, then 16. But 256 should be Enough as well as Easy.

>> Also, unless a strict discipline is imposed, maintaining ACL
>> permissions is harder and thus there is the problem that the system
>> might become insecure because of the inconsistency of ACL (few
>> sysadmin fully understand this mechanism)  as well as difficulty of
>> maintaining ACL for existing files in typical operations like
>> backup/restore, copying, etc. "
>
> So first he says that trying to do this with traditional Unix/Linux
> groups would proliate to a ton of strange group names,

They wouldn't necessarily be Strange. For example, http would mutate 
into http-ro and http-rw. But if you are willing to let Everyone read 
http files, you can simply use World Access, so httpd-ro goes away, and 
http-rw just becomes http. You might want certain Keys or Passwords in 
the cgi-bin directory only readable by http tho.

> which would be
> impossible to maintain if you have 20-30 groups you have to assign to
> user to get access to all fragments of the system. In other words, using
> traditional "chmod" in enterprise security is complex and hard to
> maintain.

I also just shows hot to make group include other groups as well as 
exclude members and groups, so things would become easier. And that IS 
compatible, only requiring a small change to Login Code.

> And then he claims that the simpler, fewer groups, needed by simple ACLs
> are hard to maintain? Sounds to me it's the other way around.

Well, the command and permissions are different. Do ACLs override Basic 
Permissions, or vice versa? Can other groups/members be excluded as well 
as added?

> I'm not
> sure how he imagines doing the security - but JUST LIKE with chmod, we
> usually configure the directories only and let the directory dictate the
> setup of each file.

Sadly, the SGID bit on Directories of NOT the default. Id File ACLs 
inherit from the Directory, then kudos.

> So you have the exact same number of entry points to
> manage - however, with ACLs you have much fewer groups to manage member
> ships off, and adopting to changing requirements is a lot easier.

Did you mean "memberships of"? I'll read it that way.

> The fact that few system admins understand it, is not really an
> argument. They can learn. If they refuse to learn, we'll find someone
> else who can get the job done.

Maybe you will. As far as I know, Very Few people use ACLs, altho with 
Identity Management and LDAP, this may change. But like I said, Group 
Manage is mostly done poorly, no matter HOW it is done.

> So if the argument is that ACLs are hard
> because the admins don't want to learn about them, and hence mess them
> up - I think it's a pretty weak argument.

Once again, I am not about to adopt every Crazy Scheme that comes down 
the pike. When I have the Choice, I will choose the Simpler Version.

>> A few quotes:
>>
>> Also, unless a strict discipline is imposed, maintaining ACL permissions
>> is harder and thus there is the problem that the system might become
>> insecure because of the inconsistency of ACL (few sysadmin fully
>> understand this mechanism)  as well as difficulty of maintaining ACL for
>> existing files in typical operations like backup/restore, copying, etc.
>
> And as you see above - I don't agree with the interpretation.  It's
> really unfounded; seems to be based primarily on Solaris and FreeBSD
> which to me are irrelevant.

If you are saying you only care what Linux does, I mostly agree, as in 
the Long View I think other forms of UNIX will die off. And yet, Basic 
Permissions work Everywhere.

>>> If you can restrict all file access to use-cases by a single process or
>>> a single family of processes, you're right - no need for ACLs.
>>
>> I think you can include everyone, but I tend to support the idea that
>> Everybody has Read Access to Everything by Default, the Original UNIX
>> model. If you want things to be private, you can turn off world read on
>> a directory or in umask.
>
> From an enterprise application perspective, this is not a sound
> assumption. And quite frankly, I don't want ALL files readable by
> everyone on a box where we assume multiple users connect to. So I don't
> know where you got the idea it's what Original Unix was all about. To my
> knowledge, /etc/passwd, /home/* etc. has never defaulted to world-read
> among a lot of files on Unix.

Yes, the original UNIX assumption was that everything was readable by 
evreyone. UNIX is about Sharing. Or course, mail directories were 
Private, as well as SSH Keys and files containing Passwords. And /usr 
was the original /home. Default umask is 22 on most systems.

>>>> I think that some people want ACLs in UNIX because they exist in Windows
>>>> and they want to deal with the same model.
>>>
>>> As you pointed out, ACLs isn't exactly a Windows invention. It's a quite
>>> common and standard approach to access control.
>>
>> ACLs are based on POSIX 1e, a Standard that has been Abandoned.
>
> Ehh no. FreeBSD maybe. Not Linux (1003.1e draft 17 is what is used for
> the Linux kernel).

Err, Yes. I was attempting to research the History of ACLs via Google 
without much success. It all seems to come back to Posix 1003.1e or 
1003.6. Also, Solaris and NFSv4 ACLs are mentioned which seem to be 
different.

>>
>> What does that tell you?
>
> Nothing relevant for this discussion?

I have a Better Quote, but it deserves its own posting.
>
>> I came across an interesting article:
>>
>> Also, unless a strict discipline is imposed, maintaining ACL permissions
>> is harder and thus there is the problem that the system might become
>> insecure because of the inconsistency of ACL (few sysadmin fully
>> understand this mechanism)  as well as difficulty of maintaining ACL for
>> existing files in typical operations like backup/restore, copying, etc.
>
> Again - that's a quote from your link that I already addressed earlier.
> I find this very badly argued. In particular since the alternative is
> even messier if not impossible.

The example they used was "chmod a-w files..." in an attempt to make a 
file Read Only. Unfortunately, ACLs may still allow writes. BAD!

>>
>> Ironically, I might even support SELinux if it promises to Kill Off
>> ACLs. However, I would like to see SELinux merged with AppArmor and/or
>> any and all other Mandatory Access Controls systems.
>
> SELinux is not a replacement for ACLs. It suffers from the same
> limitations that our "chmod" has - only one context per file.

OK, so much for that then.

JIM




More information about the Novalug mailing list