Permission denied when accessing hidden files and folders

[peara]

Asking ctags to read from hidden files or directories fails:

ctags --options=/home/peara/.vim
ctags: cannot open option directory "/home/peara/.vim" : Permission denied

I speculate that a similar failure will occur if ctags is asked to examine files outside the user's home directory.

(Originally described in https://github.com/universal-ctags/ctags/issues/2017.)

implementation notes

Currently, this builds ctags with the home interface. However, this plugin only allows access to non-hidden files in home directory.

One possible fix is to use persornal-files interface which allows access of such files. However, this only allows access to particular filenames specified in the snap build (eg. ~/ctags.d) Users will still be unable to access files with names other than those we specify.

Another possible fix is to build the snap in "classic" mode. This requires removing the 'strict' declaration in our snapcraft.yaml. I'm not yet sure what the trade-offs are. I'll go read...

[tartley]

If we need to release in classic mode, this is the request process: https://forum.snapcraft.io/t/process-for-reviewing-classic-confinement-snaps/1460

[tartley]

When this is fixed, maybe add a comment to these, so that interested people hear about it: https://github.com/universal-ctags/ctags/issues/2017 https://github.com/universal-ctags/ctags-snap/pull/5

[endoped]

Not entirely sure if this is related, but I get a similar error when trying to create a tags file on an external HD

ctags -R src/

produces

ctags: cannot open tag file : Permission denied

This is the external drive I'm trying this on:

   *-volume:3
                description: Windows NTFS volume
                vendor: Windows
                physical id: 4
                bus info: scsi@0:0.0.0,4
                logical name: /dev/sda4
                version: 3.1
                serial: aee2-38fc
                size: 965MiB
                capacity: 979MiB
                capabilities: boot precious readonly hidden nomount ntfs initialized
                configuration: clustersize=4096 created=2019-05-14 23:37:20 filesystem=ntfs label=Windows RE tools modified_by_chkdsk=true mounted_on_nt4=true name=Basic data partition resize_log_file=true state=dirty upgrade_on_mount=true

[tartley]

@en0ped Thanks for the details. Yep, it looks like this is another symptom of the same underlying problem. Namely that snaps cannot, by default, access any files. The current snap has enabled access to the user's home directory, but we cannot use that mechanism to enable access to the whole filesystem.

It looks to me that to fix all this, I'm going to have to declare the snap as "classic mode", which requires manual approval by the snap store.

[tartley]

From man universal-ctags (installed using the apt), these are the things I spotted that snaps might not have access to:

FILES

• $HOME/.ctags.d/*.ctags
• .ctags.d/*.ctags
• ctags.d/*.ctags

Experiments confirm that apt universal-ctags does read these, while our snap does not.

ENV VARS

• CTAGS (contains options? Do snaps see env vars? Try it out.)

OPTIONS

That result in file system access in addition to scanning source files:

-f tagfile -o tagfile -L file # containing file names to scan --options=pathname # contains additional command line options # searches ["$d/$pathname" for d in $optlib], then "$pathname"

(see ctags-optlib to figure what optlib means)

[tartley]

Asking whether the personal-files interface could allow access to config files using wildcards: https://forum.snapcraft.io/t/the-personal-files-interface/9357/8?u=tartley

[tartley]

FWIW, I've confirmed that building the snap using 'classic' confinement allows ctags to read all hidden config files, but I haven't yet released this, as it requires manual review by the store, and I want to investigate all other options before committing to it.

[tartley]

Trying my best to use 'personal-files' interface, but failing: Here I bleat for help in the snapcraft forums: https://forum.snapcraft.io/t/help-needed-using-personal-files-interface/14031

[tartley]

The snap's latest revision (13) uses the 'personal-files' interface to allow access to ~/.ctags.d. For now the user must manually grant permission with a 'snap connect' command shown in the snap description. The store has granted my request for them to make that connection automatically when users install the snap, which will happen imminently.

This does not allow access to arbitrary directories like the one @peara specified using '--options'. I think I've taken the 'personal-files' solution as far as I can take it, and will now have to request classic mode to fix their problem.

[tartley]

It should be noted that @peara's problem could be worked around by renaming the directory containing the config files to either:

• not be a hidden directory (ie not start with a dot), or
• not be a top-level directory (eg ~/config/.vim should work.)

I appreciate this is not always feasible. Just broadcasting what I know.

[tartley]

FYI I'm asking snapstore if we can change our snap to 'classic', which should fix this: https://forum.snapcraft.io/t/classic-confinement-request-for-universal-ctags/14687

It seems to take a few days for manual review of security-related requests like this, so I'm not sure whether it'll happen before people disappear for Christmas, etc.

[tartley]

@en0ped Hey there. Where does your external hard drive get mounted? i.e. What's the full absolute path of your 'src' directory? Thanks.

[tartley]

Old news now, but FYI the above request for a change to 'classic' was denied, so a generic fix for all the above issues is not going to happen. I'll review, apply any fixes we can for individual cases (e.g. granting access to /tmp), make sure the situation is documented properly.