<font size=2 face="sans-serif">Regarding &quot;policy engine&quot;/inodescan
and symbolic links. &nbsp;</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. &nbsp;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. &nbsp;</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... &nbsp;<br> &nbsp; &nbsp;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: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">Aaron Knister &lt;aaron.s.knister@nasa.gov&gt;</font><br><font size=1 color=#5f5f5f face="sans-serif">To: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">&lt;gpfsug-discuss@spectrumscale.org&gt;</font><br><font size=1 color=#5f5f5f face="sans-serif">Date: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">07/22/2016 06:37 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject: &nbsp; &nbsp;
&nbsp; &nbsp;</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: &nbsp; &nbsp;
&nbsp; &nbsp;</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>&gt; In a word, no. I can't blame anyone for suspecting that there's yet<br>&gt; another hidden flag somewhere, given our track record, but there's<br>&gt; nothing hidden on this one, there's just no code to implement<br>&gt; O_NOFOLLOW. This isn't Posix, and we just never put it in. This would
be<br>&gt; a reasonable thing to have, so if you feel strongly enough about it
to<br>&gt; open an RFE, go for it.<br>&gt;<br>&gt; yuri<br>&gt;<br>&gt; Inactive hide details for &quot;Knister, Aaron S. (GSFC-606.2)[COMPUTER<br>&gt; SCIENCE CORP]&quot; ---07/21/2016 09:05:11 AM---Hi Everyone, I've&quot;Knister,<br>&gt; Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]&quot; ---07/21/2016 09:05:11<br>&gt; AM---Hi Everyone, I've noticed that many GPFS commands (mm*acl,mm*attr)<br>&gt; and API calls (in particular the<br>&gt;<br>&gt; From: &quot;Knister, Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]&quot;<br>&gt; &lt;aaron.s.knister@nasa.gov&gt;<br>&gt; To: gpfsug main discussion list &lt;gpfsug-discuss@spectrumscale.org&gt;,<br>&gt; Date: 07/21/2016 09:05 AM<br>&gt; Subject: [gpfsug-discuss] GPFS API O_NOFOLLOW support<br>&gt; Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>&gt;<br>&gt; ------------------------------------------------------------------------<br>&gt;<br>&gt;<br>&gt;<br>&gt; Hi Everyone,<br>&gt;<br>&gt; I've noticed that many GPFS commands (mm*acl,mm*attr) and API calls
(in<br>&gt; particular the putacl and getacl functions) have no support for not<br>&gt; following symlinks. Is there some hidden support for gpfs_putacl that<br>&gt; will cause it to not deteference symbolic links? Something like the<br>&gt; O_NOFOLLOW flag used elsewhere in linux?<br>&gt;<br>&gt; Thanks!<br>&gt;<br>&gt; -Aaron_______________________________________________<br>&gt; gpfsug-discuss mailing list<br>&gt; gpfsug-discuss at spectrumscale.org<br>&gt; </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>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; gpfsug-discuss mailing list<br>&gt; gpfsug-discuss at spectrumscale.org<br>&gt; </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>&gt;<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 &quot;signature.asc&quot; 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>