ianb@ocf.Berkeley.EDU (Ian Barkley) (11/20/90)
Hello. We are running a bunch of Apollo DN3500's & a 4500, in bsd4.3/Domain 10.2. Ever since we upgraded to 10.2, we have had problems with file permissions. Whenever a file is created, it has permissions -rwxrwxrwx+, regardless of umask statements. lsacl shows: ianb.%.% prwx- %.ocf.% prwx- %.%.ucb [Ignore] %.%.% prwx- Chmod works fine, and files created under 10.1 kept their old permissions (mostly - we had a few tar file problems, but that's another story....) Anyway, does anyone know what's wrong and, more to the point, how to fix it? And what does that + mean on the end of the ls? Thanks in advance, -Ian Barkley Open Computer Facility staff ianb@ocf.berkeley.edu
davids@mondo.engin.umich.edu (David Snearline) (11/20/90)
In article <IANB.90Nov19175622@tempest.ocf.Berkeley.EDU> ianb@ocf.Berkeley.EDU (Ian Barkley) writes: >Hello. We are running a bunch of Apollo DN3500's & a 4500, in bsd4.3/Domain >10.2. > >Ever since we upgraded to 10.2, we have had problems with file permissions. >Whenever a file is created, it has permissions -rwxrwxrwx+, regardless of >umask statements. lsacl shows: >ianb.%.% prwx- >%.ocf.% prwx- >%.%.ucb [Ignore] >%.%.% prwx- > >Chmod works fine, and files created under 10.1 kept their old permissions >(mostly - we had a few tar file problems, but that's another story....) Anyway, >does anyone know what's wrong and, more to the point, how to fix it? And what >does that + mean on the end of the ls? > >Thanks in advance, >-Ian Barkley > Open Computer Facility staff > ianb@ocf.berkeley.edu > If you want the files you create to inheirit permissions based on the current umask, try 'chacl -B .' This will give you standard BSD file inheiritance permissions, and will kill any special ACL's. 'chacl -S .' will do the same thing except give you standard System V ACL's. Look at the man page for chacl to see what the other options are. You probably want to note the stuff on "directory inheiritance rights". You can specify both U (umask) and P (process) also. The '+' at the end of the ls just means that you have non-BSD/SysV acl's attached to it. -- ----------------------------------------------------------------------------- | David Snearline | CAEN Operations/Mac Systems | | davids@mondo.engin.umich.edu | University of Michigan Engineering | -----------------------------------------------------------------------------
thompson@ELROND.SSEC.HONEYWELL.COM (John Thompson) (11/21/90)
> Hello. We are running a bunch of Apollo DN3500's & a 4500, in bsd4.3/Domain > 10.2. > > Ever since we upgraded to 10.2, we have had problems with file permissions. > Whenever a file is created, it has permissions -rwxrwxrwx+, regardless of > umask statements. lsacl shows: > ianb.%.% prwx- > %.ocf.% prwx- > %.%.ucb [Ignore] > %.%.% prwx- It sounds like, when you went to 10.2, the directory's ACLs were munged -- probably to Aegis-style ACLs. Try doing an 'lsacl -l' on the file, and on the directory where the file is. My suspicion is that you will find the object to have some 'extended' ACL entries, and the directory to not use Unix inheritance. For example -- here's a directory ACL listing of a Unix dir on our system -- frodo 7 > lsacl -l //tolkien/bsd4.3 -- Object ACL: -- Network-wide access allowed -- Required entries: -- root.%.% prwx- -- %.sys_admin.% -rwx- -- %.%.none [Ignore] -- %.%.% -r-x- -- Extended entry mask: ----- -- Initial Directory ACL: -- Network-wide access allowed -- Required entries: -- [Process] [Umask] -- [Process] [Umask] -- %.%.none [Ignore] -- %.%.% [Umask] -- Extended entry mask: ----- -- Initial File ACL: -- Network-wide access allowed -- Required entries: -- [Process] [Umask] -- [Process] [Umask] -- %.%.none [Ignore] -- %.%.% [Umask] -- Extended entry mask: ----- -- and here's a listing of an Aegis directory on our system -- frodo 8 > lsacl -l //tolkien/com -- Object ACL: -- Network-wide access allowed -- Required entries: -- root.%.% prwx- -- %.sys_admin.% -rwx- -- %.%.none [Ignore] -- %.%.% -r-x- -- Extended entry mask: ----- -- Initial Directory ACL: -- Network-wide access allowed -- Required entries: -- root.%.% prwx- -- %.sys_admin.% -rwx- -- %.%.none [Ignore] -- %.%.% -r-x- -- Extended entry mask: ----- -- Initial File ACL: -- Network-wide access allowed -- Required entries: -- root.%.% prwx- -- %.sys_admin.% -rwx- -- %.%.none [Ignore] -- %.%.% -r-x- -- Extended entry mask: ----- The important thing to note here is the Unix inheritance scheme. The Aegis directory specifies certain explicit rights and ownerships for objects created underneith it; the Unix directory specifies that ownership and rights depend on the creating process, and the umask of the process. Keep in mind that Domain/OS is _NOT_ real unix -- it's a clever simulation. The owner and rights of files/directories are determined by the setting of the initial-ACL entries in the directory that contains the new object. I suspect that you'll find your ACLs to be a mishmash between Aegis and Unix. This is fine (we do it in several locations) but probably not what you intended. > Chmod works fine, and files created under 10.1 kept their old permissions > (mostly - we had a few tar file problems, but that's another story....) Anyway, > does anyone know what's wrong and, more to the point, how to fix it? And what > does that + mean on the end of the ls? The '+' at the end is signifying that the ACL entry contains some information not display-able by the Unix 'ls' command. This may be some extended entries, or it may be from the 'p' flag being set on the 'group' and 'world' entries. It will also be set if the 'org' entry is not '[ignored],' since bsd Unix doesn't have org rights. (The (p)rotect flag allows that person/group/org/world/extendeed-entry to change rights on the object. Basically, that person can make the rights anything he wants to, including changing the person/group/org fields.) Hope this helps you out.... John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)