Jack, you ask why "readonly" - Margaret explains this - it is because IFS supports multiple file system semantics - the Unix feel of it is only 1 such semantic style, it also has to support IBM i semantics and PC semantics - the latter is the source of the READONLY thing - just right-click any file in Windows and look at properties - at the bottom, usually, are checkboxes for Read-only, Hidden, and Archive - and maybe System.
So I think I can safely say that the IBM i is not "becoming" a Unix box - if you are in QOpenSys, it is definitely that, being where PASE wants to work. It has always had support for POSIX semantics.
Now security in the IFS has to reckon with all 3 of these security semantics at the same time. Margaret suggests the first thing to do is to set up security using the semantics native to where the object is - so QOpenSys would start with Unix semantics, /QSYS/ would start with IBM i semantics, and outside of those, maybe start with Windows semantics - although I don't know if many of us use Read-only of Hidden or Check-out or Check-in (those also come from the PC/Windows semantics).
Margaret is __the__ expert - she was the chief architect for IFS for 16 years until recently. Listen to her security session in the IFS Bootcamp at COMMON - I've been repeating her words here, probably not adequately enough - and I repeat - the IFS is not just Unix and isn't becoming that - different parts of it are best managed using Unix semantics.
Regards
Vern
On Fri, 5 Apr, 2024 at 8:07 AM, Jack Woehr <jack.woehr@xxxxxxxxxxx> wrote:
To: midrange systems technical discussion
You're right, Rob
$ echo woof >foo
$ ls -l foo
-rw-r--r-- 1 jwoehr 0 5 Apr 5 09:00 foo
$ cl "chgatr obj('/home/jwoehr/foo') atr(*readonly) value(*yes)"
CPFB414: Attributes changed for 1 objects. 0 objects not changed.
$ ls -l foo
-rw-r--r-- 1 jwoehr 0 5 Apr 5 09:00 foo
$ rm -rf foo
rm: cannot remove 'foo': System call error number 3500.
$ cl "chgatr obj('/home/jwoehr/foo') atr(*readonly) value(*no)"
CPFB414: Attributes changed for 1 objects. 0 objects not changed.
$ rm foo
$ ls -l foo
ls: cannot access 'foo': A file or directory in the path name does not exist.
So why use these attributes (or authorities) ... What is provided that Unix doesn't provide in this regard.
The attributes for CCSID, yes. Readonly? Why?
I suppose it prevents finger slips.
________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>> on behalf of Rob Berendt <robertowenberendt@xxxxxxxxx<mailto:robertowenberendt@xxxxxxxxx>>
Sent: Friday, April 5, 2024 6:23 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>>
Subject: Re: Read-only dir & files within?
Jack Woehr,
Look at the documentation for this command:
CHGATR OBJ('/mylink') ATR(*READONLY) VALUE(*YES)
https://www.ibm.com/docs/en/i/7.5?topic=ssw_ibm_i_75/cl/chgatr.html<https<
https://www.ibm.com/docs/en/i/7.5?topic=ssw_ibm_i_75/cl/chgatr.html<https>://www.ibm.com/docs/en/i/7.5?topic=ssw_ibm_i_75/cl/chgatr.html><www.ibm.com/docs/en/i/7.5?topic=ssw_ibm_i_75/cl/chgatr.html>>
It's not an authority. It's an attribute.
midrange.com
