From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Linux (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.

Does it support file descriptor passing across isolation contexts?[edit]

Most unices support a mechanism to 'pass' a file descriptor through a socket. ( For example, you might have a virus scanning daemon running as an unpriviledge user, and then to scan a file, a client can pass an open file descriptor over the socket to the virus scanning daemon. The scanning daemon can then read that file to search for viruses, even though it is running under a user that normally cannot access the file.

Does LXC allow file descriptor passing of this type between security contexts?

PS- I've asked the same question about Talk:LXC, Talk:Linux-VServer and Talk:OpenVZ (talk) 20:42, 11 November 2012 (UTC)

Please note that Wikipedia talk pages are for discussing *changes* to the article, and not a support forum for the product in question. (WP:TALK, WP:NOTFORUM) -- intgr [talk] 15:00, 12 November 2012 (UTC)
It is not a support question. It is a clarifying question, and is important for defining the isolation guarantees of these methods. (talk) 03:33, 13 November 2012 (UTC)
Let me clarify. Right now, the article starts with "LXC ... method for running multiple isolated Linux systems (containers) on a single control host." (emphasis mine). I am saying that the term 'isolated' has gradations of meaning. That is why the Operating system-level virtualization article has a table describing that isolation in at least 9 dimensions (they call it 'features'). My question (I was the original poster) was meant to get more information to improve the article. (talk) 03:42, 13 November 2012 (UTC)
Whatever intgr implied, you will most probably not get a qualified answer to such questions on the Wikipedia Talk page. Wikipedia users are lucky people with the knowledge still bother to write articles, do not expect them to hang around ;-) User:ScotXWt@lk 10:07, 9 April 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── As far as I can see, passing file descriptors through Unix sockets works between namespaces, just as Unix sockets can be used between namespaces if their associated files are accessible. Have a look at this explanation and net/unix/af_unix.c for Unix sockets and namespaces in general, and net/core/scm.c and its scm_fp_copy() for actual handling of SCM_RIGHTS. No namespaces-related checks are there, as far as I can see.

So, how do we improve an article with this kind of info? Who comes to Wikipedia to read about such details? :) — Dsimic (talk | contribs) 04:16, 11 April 2014 (UTC)

Evading from LXC[edit]

Is this issue still present? Some information would be good, as the weblink does not present this information. -- (talk) 17:02, 19 January 2013 (UTC)

Requested move[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: already closed; no consensus for the proposed title, as per the discussion below. Dekimasuよ! 00:51, 12 October 2014 (UTC)

LXC (LinuX Containers)Linux containers – To me, there's little sense in having both an acronym and full name as a title. Maybe "LXC (software)" could be another option for the article title. — Dsimic (talk | contribs) 17:35, 25 September 2014 (UTC)

Move back to LXC because that's its WP:COMMONNAME.
@Petebutt: I think the whole move and disambiguation page were misguided:
  1. Disambiguation pages are usually not necessary when there are just 2 terms, it's solved using hatnotes such as {{About}}
  2. The other entry on the dab page is Curtiss-Wright LXC, which is a redirect to Curtiss-Wright CA-1. The latter article doesn't even mention LXC, so this doesn't even seem like a qualifying disambiguation page entry. WP:DABPIPE says: "Subject to certain exceptions as listed below, piping or redirects should not be used in disambiguation pages" and the relevant exception states "the redirect could serve as an alternative name for the target article, meaning an alternative term that is already in the article's lead section"
Is this usage of "LXC" really common enough that it warrants a mention? There are just 26 Google results. -- intgr [talk] 18:16, 25 September 2014 (UTC)
Anyway, "Linux" should be capitalized. — Dsimic (talk | contribs) 04:49, 26 September 2014 (UTC)
"Linux" is the kernel, "linux" is the OS (ie. GNU + Linux). It would work either way; most disambiguators are lowercase. -- (talk) 04:00, 27 September 2014 (UTC)
  • Move to LXC or LXC (software). Having both the acronym and its full name in the title is just silly. JIP | Talk 05:23, 26 September 2014 (UTC)
  • Comment: Well, it seems that @BD2412: already reverted the page move and added a hatnote. Should we close this discussion? -- intgr [talk] 12:07, 26 September 2014 (UTC)
    • Per WP:RM, a bold move that is contested should be reverted immediately so that the proposal of that move can be discussed. In this case the move also set up a WP:TWODABS violation, as there is a clear primary topic between a reasonably widely available software system, and a single airplane designated within a class. bd2412 T 12:42, 26 September 2014 (UTC)
    • As BD2412 described it, creating the disambiguation page was against WP:TWODABS so I'd say that this discussion should be closed. — Dsimic (talk | contribs) 17:58, 26 September 2014 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.