[gpfsug-discuss] GPFS API O_NOFOLLOW support

[Marc A Kaplan]

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-0002.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-0002.gif>