[gpfsug-discuss] GPFS API O_NOFOLLOW support
Marc A Kaplan
makaplan at us.ibm.com
Mon Jul 25 22:46:01 BST 2016
Unfortunately there is always a window of time between testing the file
and acting on the file's pathname.
At any moment after testing (finding) ... the file could change, or the
same pathname could be pointing to a different inode/file.
That is a potential problem with just about every Unix file utility and/or
script you put together with the standard commands...
find ... | xargs ...
mmapplypolicy has the -e option to narrow the window by retesting just
before executing an action.
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
and then they are doing so either carelessly without communicating or
one is deliberately trying to cause trouble for the other!
From: Aaron Knister <aaron.s.knister at nasa.gov>
To: <gpfsug-discuss at spectrumscale.org>
Date: 07/25/2016 03:51 PM
Subject: Re: [gpfsug-discuss] GPFS API O_NOFOLLOW support
Sent by: gpfsug-discuss-bounces at spectrumscale.org
Thanks Marc. In my mind the issue is a timing one between the moment the
policy engine decides to perform an action on a file (e.g. matching the
path inode/gen number with that from the inode scan) and when it
actually takes that action by calling an api call that takes a path as
an argument. Your suggestion in #3 is the route I think I'm going to
take here since I can call acl_get_fd after calling open/openat with
O_NOFOLLOW.
On 7/24/16 11:54 AM, Marc A Kaplan wrote:
> Regarding "policy engine"/inodescan and symbolic links.
>
> 1. Either the MODE and MISC_ATTRIBUTES properties (SQL variables) can be
> tested to see if an inode/file is a symlink or not.
>
> 2. Default behaviour for mmapplypolicy is to skip over symlinks. You
> must specify...
>
> *DIRECTORIES_PLUS which ...*
>
> Indicates that non-regular file objects (directories, symbolic links,
> and so on) should be included in
> the list. If not specified, only ordinary data files are included in the
> candidate lists.
>
> 3. You can apply Linux commands and APIs to GPFS pathnames.
>
> 4. Of course, if you need to get at a GPFS feature or attribute that is
> not supported by Linux ...
>
> 5. Hmmm... on my Linux system `setfacl -P ...` does not follow symlinks,
> but neither does it set the ACL for the symlink...
> Googling... some people consider this to be a bug, but maybe it is a
> feature...
>
> --marc
>
>
>
> From: Aaron Knister <aaron.s.knister at nasa.gov>
> To: <gpfsug-discuss at spectrumscale.org>
> Date: 07/22/2016 06:37 PM
> Subject: Re: [gpfsug-discuss] GPFS API O_NOFOLLOW support
> Sent by: gpfsug-discuss-bounces at spectrumscale.org
> ------------------------------------------------------------------------
>
>
>
> Thanks Yuri! I do wonder what security implications this might have for
> the policy engine where a nefarious user could trick it into performing
> an action on another file via symlink hijacking. Truthfully I've been
> more worried about an accidental hijack rather than someone being
> malicious. I'll open an RFE for it since I think it would be nice to
> have. (While I'm at it, I think I'll open another for having chown call
> exposed via the API).
>
> -Aaron
>
> On 7/22/16 3:24 PM, Yuri L Volobuev wrote:
>> In a word, no. I can't blame anyone for suspecting that there's yet
>> another hidden flag somewhere, given our track record, but there's
>> nothing hidden on this one, there's just no code to implement
>> O_NOFOLLOW. This isn't Posix, and we just never put it in. This would
be
>> a reasonable thing to have, so if you feel strongly enough about it to
>> open an RFE, go for it.
>>
>> yuri
>>
>> Inactive hide details for "Knister, Aaron S. (GSFC-606.2)[COMPUTER
>> SCIENCE CORP]" ---07/21/2016 09:05:11 AM---Hi Everyone, I've"Knister,
>> Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]" ---07/21/2016 09:05:11
>> AM---Hi Everyone, I've noticed that many GPFS commands (mm*acl,mm*attr)
>> and API calls (in particular the
>>
>> From: "Knister, Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]"
>> <aaron.s.knister at nasa.gov>
>> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>,
>> Date: 07/21/2016 09:05 AM
>> Subject: [gpfsug-discuss] GPFS API O_NOFOLLOW support
>> Sent by: gpfsug-discuss-bounces at spectrumscale.org
>>
>>
------------------------------------------------------------------------
>>
>>
>>
>> Hi Everyone,
>>
>> I've noticed that many GPFS commands (mm*acl,mm*attr) and API calls (in
>> particular the putacl and getacl functions) have no support for not
>> following symlinks. Is there some hidden support for gpfs_putacl that
>> will cause it to not deteference symbolic links? Something like the
>> O_NOFOLLOW flag used elsewhere in linux?
>>
>> Thanks!
>>
>> -Aaron_______________________________________________
>> gpfsug-discuss mailing list
>> gpfsug-discuss at spectrumscale.org
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>>
>>
>>
>> _______________________________________________
>> gpfsug-discuss mailing list
>> gpfsug-discuss at spectrumscale.org
>> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>
>
> --
> Aaron Knister
> NASA Center for Climate Simulation (Code 606.2)
> Goddard Space Flight Center
> (301) 286-2776
>
> [attachment "signature.asc" deleted by Marc A Kaplan/Watson/IBM]
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
--
Aaron Knister
NASA Center for Climate Simulation (Code 606.2)
Goddard Space Flight Center
(301) 286-2776
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160725/cf73fe30/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21994 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160725/cf73fe30/attachment.gif>
More information about the gpfsug-discuss
mailing list