<font size=2 face="sans-serif">Unfortunately there is always a window
of time between testing the file and acting on the file's pathname.</font><br><font size=2 face="sans-serif">At any moment after testing (finding)
... the file could change, or the same pathname could be pointing to a
different inode/file.</font><br><br><font size=2 face="sans-serif">That is a potential problem with just
about every Unix file utility and/or script you put together with the standard
commands...</font><br><font size=2 face="sans-serif">find ... | xargs ...<br></font><br><font size=2 face="sans-serif">mmapplypolicy has the -e option to narrow
the window by retesting just before executing an action.</font><br><br><font size=2 face="sans-serif">Of course it's seldom a real problem
-- you have to think about scenarios where two minds are working within
the same namespace of files</font><br><font size=2 face="sans-serif">and then they are doing so either
carelessly without communicating or one is deliberately trying
to cause trouble for the other!</font><br><br><img align=left src=cid:_1_0F3AFA180F3AF7AC007791EB85257FFB alt="Marc A Kaplan" style="border:0px solid;"><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/25/2016 03:51 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 Marc. In my mind the issue is a timing one
between the moment the <br>policy engine decides to perform an action on a file (e.g. matching the
<br>path inode/gen number with that from the inode scan) and when it <br>actually takes that action by calling an api call that takes a path as
<br>an argument. Your suggestion in #3 is the route I think I'm going to <br>take here since I can call acl_get_fd after calling open/openat with <br>O_NOFOLLOW.<br><br>On 7/24/16 11:54 AM, Marc A Kaplan wrote:<br>> Regarding "policy engine"/inodescan and symbolic links.<br>><br>> 1. Either the MODE and MISC_ATTRIBUTES properties (SQL variables)
can be<br>> tested to see if an inode/file is a symlink or not.<br>><br>> 2. Default behaviour for mmapplypolicy is to skip over symlinks. You<br>> must specify...<br>><br>> *DIRECTORIES_PLUS which ...*<br>><br>> Indicates that non-regular file objects (directories, symbolic links,<br>> and so on) should be included in<br>> the list. If not specified, only ordinary data files are included
in the<br>> candidate lists.<br>><br>> 3. You can apply Linux commands and APIs to GPFS pathnames.<br>><br>> 4. Of course, if you need to get at a GPFS feature or attribute that
is<br>> not supported by Linux ...<br>><br>> 5. Hmmm... on my Linux system `setfacl -P ...` does not follow symlinks,<br>> 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<br>> feature...<br>><br>> --marc<br>><br>><br>><br>> From: Aaron Knister <aaron.s.knister@nasa.gov><br>> To: <gpfsug-discuss@spectrumscale.org><br>> Date: 07/22/2016 06:37 PM<br>> Subject: Re: [gpfsug-discuss] GPFS API
O_NOFOLLOW support<br>> Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>> ------------------------------------------------------------------------<br>><br>><br>><br>> 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>> _______________________________________________<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>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></font></tt><br><BR>