[gpfsug-discuss] GPFS API O_NOFOLLOW support

[Aaron Knister]

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