getfilecon() and friends in libselinux

getfilecon() and friends in libselinux

[Joshua Brindle]

Some applications in setools, namely findcon, replcon and indexcon walk 
the filesystem and get the file context off files. Previously it was 
fairly known what filesystems supported labeling so they were defined 
during the build process but now that other filesystems (reiser, jfs and 
tmpfs) support labeling but aren't necessarilly widespread we can't 
reliably define the supported filesystems during the build process and 
expect it to work across systems.

The idea is to iterate the filesystem mount points and do a getfilecon() 
or similar on a file in it, then examine the error code returned to 
decide if the filesystem supports xattr and also supports the security 
namespace. Is this a stable API to rely on for this? Will the error 
codes remain stable?

Further, if there is ever support for contexts via psids or something 
that isn't xattr will getfilecon() also be a supported method for 
accessing those?

Joshua Brindle
Tresys Technology

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: getfilecon() and friends in libselinux

[Stephen Smalley]

On Wed, 2004-12-08 at 12:13, Joshua Brindle wrote:
> The idea is to iterate the filesystem mount points and do a getfilecon() 
> or similar on a file in it, then examine the error code returned to 
> decide if the filesystem supports xattr and also supports the security 
> namespace. Is this a stable API to rely on for this? Will the error 
> codes remain stable?

Yes, getfilecon() should return -1 with errno EOPNOTSUPP if the
filesystem does not support xattrs at all or if the filesystem does not
support the security namespace.

> Further, if there is ever support for contexts via psids or something 
> that isn't xattr will getfilecon() also be a supported method for 
> accessing those?

Yes - even if we were to implement a persistent label mapping (or
something similar to what was done for reiserfs) for a given filesystem,
we would still export it via the xattr API, and thus getfilecon() (or
lgetfilecon or fgetfilecon) would still be the preferred interface for
getting the file context.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: getfilecon() and friends in libselinux

[Casey Schaufler]

Be careful of virtual file systems (e.g. autofs,
automount) as some implementations have semantics
that differ between the mount point and contained
objects. I have seen device file system
implementations that claimed to implement extended
attributes but that had enormously odd behaviors.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: getfilecon() and friends in libselinux

[Stephen Smalley]

On Wed, 2004-12-08 at 14:36, Casey Schaufler wrote:
> Be careful of virtual file systems (e.g. autofs,
> automount) as some implementations have semantics
> that differ between the mount point and contained
> objects. I have seen device file system
> implementations that claimed to implement extended
> attributes but that had enormously odd behaviors.

Good point.  A specific example that exists today is devpts; we only
implemented fake xattr handlers for the pty nodes themselves, not for
the root directory, so getfilecon /dev/pts will fail while getfilecon
/dev/pts/0 will succeed.  Darrel Goeddel posted a patch earlier to add
support for the /dev/pts root as well, and there was some discussion of
the need for wider support for getting file contexts without needing to
patch every pseudo filesystem to export xattr handlers.  That latter
should be much easier due to the xattr code consolidation and generic
code created by James Morris, but it would still be nice to have a
fallback in the VFS for the security namespace that would just get the
security attribute from the security module.  That discussion started at
http://marc.theaimsgroup.com/?l=selinux&m=109880845227851&w=2.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.