[gpfsug-discuss] GPFS API O_NOFOLLOW support

[Marc A Kaplan]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160724/7ecff197/attachment-0001.htm>