<font size=2 face="sans-serif">Regarding "policy engine"/inodescan
and symbolic links.  </font><br><br><font size=2 face="sans-serif">1. Either the MODE and MISC_ATTRIBUTES
properties (SQL variables) can be tested to see if an inode/file is a symlink
or not.</font><br><br><font size=2 face="sans-serif">2. Default behaviour for mmapplypolicy
is to skip over symlinks.  You must specify...</font><br><br><font size=2 face="BookMaster-Bold"><b>DIRECTORIES_PLUS which ...</b></font><br><br><font size=2 face="Palatino-Roman">Indicates that non-regular file
objects (directories, symbolic links, and so on) should be included in</font><br><font size=2 face="Palatino-Roman">the list. If not specified, only
ordinary data files are included in the candidate lists.</font><font size=2 face="sans-serif"><br></font><br><font size=2 face="sans-serif">3. You can apply Linux commands and
APIs to GPFS pathnames.  </font><br><br><font size=2 face="sans-serif">4. Of course, if you need to get at
a GPFS feature or attribute that is not supported by Linux ... </font><br><br><font size=2 face="sans-serif">5. Hmmm... on my Linux system `setfacl
-P ...` does not follow symlinks, but neither does it set the ACL for the
symlink...  <br>    Googling... some people consider this to be a bug, but maybe
it is a feature...</font><br><br><font size=2 face="sans-serif">--marc</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Aaron Knister <aaron.s.knister@nasa.gov></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif"><gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">07/22/2016 06:37 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
GPFS API O_NOFOLLOW support</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>Thanks Yuri! I do wonder what security implications
this might have for <br>the policy engine where a nefarious user could trick it into performing
<br>an action on another file via symlink hijacking. Truthfully I've been <br>more worried about an accidental hijack rather than someone being <br>malicious. I'll open an RFE for it since I think it would be nice to <br>have. (While I'm at it, I think I'll open another for having chown call
<br>exposed via the API).<br><br>-Aaron<br><br>On 7/22/16 3:24 PM, Yuri L Volobuev wrote:<br>> In a word, no. I can't blame anyone for suspecting that there's yet<br>> another hidden flag somewhere, given our track record, but there's<br>> nothing hidden on this one, there's just no code to implement<br>> O_NOFOLLOW. This isn't Posix, and we just never put it in. This would
be<br>> a reasonable thing to have, so if you feel strongly enough about it
to<br>> open an RFE, go for it.<br>><br>> yuri<br>><br>> Inactive hide details for "Knister, Aaron S. (GSFC-606.2)[COMPUTER<br>> SCIENCE CORP]" ---07/21/2016 09:05:11 AM---Hi Everyone, I've"Knister,<br>> Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]" ---07/21/2016 09:05:11<br>> AM---Hi Everyone, I've noticed that many GPFS commands (mm*acl,mm*attr)<br>> and API calls (in particular the<br>><br>> From: "Knister, Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]"<br>> <aaron.s.knister@nasa.gov><br>> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>,<br>> Date: 07/21/2016 09:05 AM<br>> Subject: [gpfsug-discuss] GPFS API O_NOFOLLOW support<br>> Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>><br>> ------------------------------------------------------------------------<br>><br>><br>><br>> Hi Everyone,<br>><br>> I've noticed that many GPFS commands (mm*acl,mm*attr) and API calls
(in<br>> particular the putacl and getacl functions) have no support for not<br>> following symlinks. Is there some hidden support for gpfs_putacl that<br>> will cause it to not deteference symbolic links? Something like the<br>> O_NOFOLLOW flag used elsewhere in linux?<br>><br>> Thanks!<br>><br>> -Aaron_______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br>><br>><br>><br>><br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br>><br><br>-- <br>Aaron Knister<br>NASA Center for Climate Simulation (Code 606.2)<br>Goddard Space Flight Center<br>(301) 286-2776<br><br>[attachment "signature.asc" deleted by Marc A Kaplan/Watson/IBM]
_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><BR>